AMOF Install public AMOF

AMOF

Runtime Authority for governed AI execution

Models are workers. Runtime is authority.

AI workers can already do real work. The problem is letting them act without a boundary. AMOF is an open-source runtime and CLI for governed AI execution: it decides what a worker is allowed to do against a declared Target Set and write envelope, runs the work inside that boundary, and records Evidence so an operator can accept or reject the Result.

Observability tells you what happened. Authority determines what was allowed to happen.

Install public AMOF Understand Runtime Authority GitHub
Predator Result on the write-capable alpha: docs/NOTES.md bullet added, diff open, changes on an isolated sandbox branch, Mission sealed, acceptance unverified
Predator v3 — a real write Result on the isolated write-capable alpha. Diff, sealed Mission, acceptance state, and changes that stayed on an isolated workspace branch.

The loop

Intent becomes a Mission. Evidence stays under the Result.

A Mission is the durable unit of intent. A Run is one governed execution. The Target Set and write envelope declare the boundary before anything mutates.

Evidence sits underneath the Result. Chat is not the system of record.

Non-claims

What AMOF is not

Today

What you can do today

Public AMOF and Predator are different surfaces. Only the open-source runtime is installable.

Public AMOF

Clone and install the open-source runtime and CLI (Apache-2.0), AMOF 3.4.0 (released). It does not ship Predator.

GitHub release — v3.4.0

Predator v3

Predator is Hotshot's private operator console. An isolated write-capable alpha is live: bounded autonomous writes inside the configured Project scope, with human authority at consequential boundaries.

The problem

Models propose. Operations need authority.

Useful AI output is not enough. Executions need scope, approvals, identity, and Evidence — or operators inherit unreliable chat claims.

Proposal is cheap

Workers can draft plans and patches quickly. That does not make them trustworthy executors.

Prompts are not gates

Asking a model to be careful cannot revoke a write grant or prove a path stayed in scope.

Evidence must be durable

If it is not recorded, it is not runtime truth. Scrollback is not an audit trail.

Runtime Authority

Between human intent and AI execution

Runtime Authority owns the Mission, compiles the Target Set, delegates to Workers, enforces the write envelope, collects Evidence, and leaves Preview and Promote as human actions.

Runtime Authority lifecycle Intake to review under one system of record

  1. IntakeIntent → Mission
  2. DecisionPolicy + scope
  3. Bounded runWorkers propose
  4. EvidenceReceipts + logs
  5. ReviewRetry / promote

Runtime Authority

Owns Missions, policy, Evidence, stop authority, and release readiness

  • Plans
  • Enforces
  • Coordinates
  • Records

Models are workers. Runtime is authority.

Intake → decision → bounded execution → Evidence → review / promote

Deep dive: Runtime Authority architecture — product concept page, not a personal blog.

Predator

Private operator console

Predator v3 is Hotshot's private operator console. An isolated write-capable alpha is live.

Testers create a Project, attach a repository, and declare writable roots. Inside those roots Predator performs bounded autonomous writes on an isolated workspace branch. A write outside them is refused, reported, and recoverable by widening the roots — human authority at consequential boundaries. It never pushes to a protected branch, opens a pull request, or deploys. The loop is intent → Mission packet → write Run → Result (diff and evidence) → follow-up.

It is not in the public OSS distribution and is not a public login. Hotshot operates its own delivery on AMOF daily, including this console.

One real lifecycle, start to finish

Predator v3 first contact: WRITE-ENABLED ALPHA card, no Project yet, bounded-write authority
01 — First contact
Create Project form with sandbox repository and declared writable roots
02 — Project
Project Repositories tab: bound public sandbox with writable roots listed
03 — Repositories
Assistant compiled a Mission packet from a plain-language docs intent
04 — Intent
Director handoff in progress: sending a governed write Run
05 — Governed Run
Governed write Run executing on the write-enabled alpha
06 — Running
Result R-001 with docs/NOTES.md diff open on an isolated sandbox branch
07 — Write executed
Files and evidence under the Result: changed docs/NOTES.md, Diff and evidence entries
08 — Evidence
Settled Result with Start a new Mission and Continue this Mission
09 — Continue Mission
Refused Makefile write outside declared roots with Widen writable roots control
10 — Boundary blocked
Project edit widening writable roots from docs to docs, src
11 — Widen roots
Second Run R-002 selected, write-scope approval required, Allow Reject Edit controls
12 — Needs You

01 — First contact

    Real screens from the isolated write-capable alpha (September 2026). Bounded writes stay on an isolated workspace branch. Refused, blocked, and Needs-You states are part of the product — not hidden.

    Human-gated approvals

    Write-scope proposals fail closed until an operator approves a Binding.

    Runs and Results

    Inspect completed Runs with a Result envelope and acceptance state.

    Evidence

    Browse secret-safe run Evidence instead of trusting chat summaries.

    Write envelope

    Allowed and denied roots; deny-wins. A ceiling is not a grant.

    Direction

    Validated direction, not shipped

    These are architectural findings. They are not product claims.

    One truth core, multiple shells

    AMOF owns Mission, Run, write authority, Evidence, acceptance, and receipts. Predator is one engineering projection. An executive shell is later — architecturally sound, not built.

    Human Understanding contract

    Ordering is shipped in Predator: understanding first, evidence underneath, raw execution last. Explicit understanding fields (purpose, approach, consequence) are a proposal.

    Standing Missions

    Durable responsibility across bounded cycles is a discovery. It is not shipped and is not claimed.

    AMOF LOG

    AMOF LOG — audio deep dives

    Season 2 Episode 1 is playable here. The episode page lives on hotshot.sk.

    Season 2 · Episode 1

    Token Physics and Autonomous Context Hygiene

    Season 2 of AMOF LOG opens on token physics and autonomous context hygiene: how autonomous AI engineering stays accountable, how context is assembled with provenance, and why cryptographic receipts matter. The episode covers context hygiene across follow-on Missions, durable synthesized state, and runtime economics — treating tokens as telemetry rather than a substitute for vendor-price accounting. This is an engineering deep dive, not a product launch.

    Audio file (m4a) · Episode on hotshot.sk

    Governance and trust

    Scopes, approvals, and Evidence

    Trust comes from what the runtime can enforce, inspect, and stop.

    Governance that can be enforced

    Writable scopes

    Bounded paths and capability modes. Over-bound work fails closed.

    Approvals

    Human gates where mutation matters. Operators keep stop authority.

    Evidence

    Secret-safe receipts and run records. If unrecorded, not runtime truth.

    Runtime identity binds the loop Who ran what, under which grant, with which Evidence — replayable.
    Scope, approval, and Evidence must connect — or trust is theatre

    Writable scopes

    Bounded paths and capability modes. Over-bound work fails closed at dispatch.

    Approvals

    Write-scope and elevated mutation require an operator decision before bind.

    Mission identity

    Missions carry durable intent. Write authority lives on the Mission envelope. A Session is a resumable operator workspace, not an authority unit.

    Replay and audit

    Receipts and run records make outcomes inspectable after the fact.

    Architecture

    Workers propose. Runtime decides what is true.

    Models and tools are replaceable Workers. Runtime Authority is the system of record for Missions, Runs, Target Sets, policy, and Evidence.

    Who owns what? Runtime Authority is not an AI agent

    Runtime Authority

    System of record

    • Owns Missions and Runs
    • Owns policy and write grants
    • Owns coordination and stop
    • Owns Evidence and receipts
    • Owns release readiness

    Workers

    Replaceable cognition

    • Propose plans and patches
    • Execute bounded tool calls
    • Can be swapped under policy
    • Never own runtime truth
    • Never grant their own scope
    Runtime Authority owns truth and policy. Workers stay replaceable.

    Models as Workers

    GPT, Claude, Grok, and tools execute delegated work — they do not own grants.

    Runtime as authority

    Policy, stop, and Evidence stay outside the model.

    Governed loops

    Explicit stop conditions. Human gates where mutation matters.

    Runtime Authority explainer

    Product proof

    Named surfaces. Honest maturity.

    Public OSS — AMOF 3.4.0

    Write-Scope Authority (Apache-2.0). Installable local governed runtime. Does not ship Predator or private cloud topology. AMOF 3.4.0 is released: usable public Write-Scope lifecycle — bounded_write recognised, Binding roots replace executor roots, out-of-scope writes blocked as scope_exceeded.

    GitHub release — v3.4.0

    Predator v3

    Private operator console. Isolated write-capable alpha: bounded autonomous writes inside configured Project scope; human authority at consequential boundaries.

    Evidence-first

    Receipts, run records, and runtime logs are first-class. Missing provider cost stays unknown — never fabricated.

    Next step

    Install the public runtime. Read the architecture.

    Public OSS for Write-Scope Authority. Predator stays private.

    Install public AMOF Understand Runtime Authority