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.

LOCAL · amof demo migration

LOCAL REFERENCE SYSTEM

$ git clone https://github.com/marekhotshot/amof.git
$ cd amof
$ python3 scripts/amof.py demo migration --non-interactive

Allowed action executes. Out-of-scope action is blocked before transport. A receipt is emitted either way.

Runtime Authority

Proposal is not authority.

A worker can propose work. The runtime binds a finite grant, enforces it at execution, verifies the outcome, and writes a receipt. Chat output is not runtime truth.

The governed loop

  1. Proposalworker asks
  2. Approvaloperator grant
  3. Bindingfinite scope
  4. Executioninside the grant
  5. Verificationread back
  6. Receiptwhat happened

Later sections use this loop. They do not invent a second one.

proposal → approval → binding → execution → verification → receipt

In practice

Runtime Authority in Practice

A stranger with the public repo can execute one scenario, see an allowed action, watch out-of-scope work fail before transport, and bind the result to a promoted SHA — in about 15 minutes. No provider key. No cluster required.

LOCAL REFERENCE SYSTEM

Migration

Recommended first scenario. One object/action/state primitive. Not a migration product.

  1. Request → approval → binding
  2. Allowed migrate invokes the reference transport
  3. Wrong object / constraint / action are blocked before transport
  4. Verification → receipt

Try this locally

git clone https://github.com/marekhotshot/amof.git
cd amof
python3 scripts/amof.py demo migration --non-interactive
Public proof file

Insurance, banking, healthcare, and IAM are the same local reference.action primitive — fixtures, not product integrations. Proof files above are pinned to proof revision a342cc2.

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. The governed loop above is the authority loop; this section names who owns it.

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

Same loop as above. Human gates where mutation matters.

Private operation

How AMOF is operated privately

Predator is a private operator console used to operate AMOF workflows. It is not the public runtime, not required for amof demo, not required for public proof, and not the source of Runtime Authority truth.

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. It never pushes to a protected branch, opens a pull request, or deploys.

It is not in the public OSS distribution and is not a public login.

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.

    Governance and trust

    The same loop, enforced

    Writable scopes, approvals, and receipts are the Runtime Authority loop above — not a second model. If it is unrecorded, it is not runtime truth.

    Product proof

    Named surfaces. Honest maturity.

    Public OSS — AMOF 3.5.0

    Write-Scope Authority (Apache-2.0). Installable local governed runtime. Does not ship Predator or private cloud topology. AMOF 3.5.0 is released: Write-Scope lifecycle plus Kubernetes Capability Authority, amof demo, and public amof proof.

    Predator v3 — private

    Private operator console for operating AMOF workflows. Not required to run or inspect public proof.

    Evidence-first

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

    Next step

    Run the proof. Inspect the evidence.

    Public AMOF is executable today. Predator stays private.