What is AER-1?

The problem it answers

When an AI agent finishes a job, it hands back a summary: done, sent, fixed, checked. The summary is the agent grading its own homework. If the record of the work lives inside the same system that did the work, it can be edited, trimmed, or never written, and the person receiving the summary has no way to tell.

AER-1 moves the record outside the agent's say-so. The execution system saves each step as it happens, and a hash commitment over the saved bytes is fixed at that moment. From then on, the record can be checked by anyone, including people who trust neither the agent nor the operator. The summary can still say whatever it says. The receipt is what gets checked.

Who made AER-1, and where it lives

AER-1 was created by Brennan Zambo, the creator of Zambo, the verifiable work layer for AI: tools behind one endpoint, continuity that carries work across AIs, and a verifiable receipt for every job. He wrote the format, published it, and maintains the conformance kit that implementations test against.

The specification lives at the IETF as Internet-Draft draft-zambo-aer1, currently at revision 23. An Internet-Draft is a public working document on the standards track: anyone can read it, implement it, and file findings against it. It is not a finalized standard, and this page will never call it one. The draft text is the normative definition; this page is its plain-language companion. For the mechanics, conformance levels, and interop history, see the AER-1 deep-dive page.

What an AER-1 receipt contains

A receipt is a small record with a deliberately minimal checkable core:

• Receipt identifier. A stable ID that locates this exact record.
• Creation time. When the execution happened, ordering the record.
• The steps, in order. Each step names the tool that ran and the caller scope it ran under.
• Inputs and the saved result. The exact bytes of the result as observed, preserved so a verifier can reproduce them byte for byte.
• Provenance. Labels recording where each step's output came from, so a reader can see the origin of the work, not just its shape.
• Commitments. A SHA-256 hash commitment over each step's canonical bytes, chained step to step and sealed under one Merkle root for the whole run.

Producers may add fields of their own for their own tooling. A verifier never rejects a receipt just for carrying extra fields; the core above is what every implementation shares, and it is the only part the check depends on.

What an AER-1 receipt proves, and what it does not

That narrow scope is deliberate. A claim this small can be checked by anyone, anywhere, with no account and no trust in the producer, and that is what lets the format be open instead of being one vendor's report.

How to verify an AER-1 receipt

Verification is one computation, and it needs nothing from the party being verified:

1. Take the saved bytes from the receipt.
2. Compute SHA-256 over them.
3. Compare with the commitment the receipt carries.

If they match, the result you are reading is the result that was recorded. If they do not, the record was changed after the fact. The fastest way to see it: zambo.dev/verify/ runs the check in your browser, and the live demo mints a fresh receipt on a real call so you can verify one end to end. The hub also carries a step-by-step verification guide.

How implementations check themselves

AER-1 ships with a conformance kit: published test vectors, meaning known inputs with expected outputs, including attack cases such as changed bytes, reordered steps, and dropped steps. An implementer runs the vectors locally and compares. If every expected commitment and every expected rejection matches, the implementation conforms, and the implementation never had to ask the author for permission or a test account.

The kit and the draft move together: the specification only describes behavior the kit already exercises. Independent implementations also verify each other's receipts, so conformance is checked across codebases, not just against the reference one. The kit lives with the draft materials in the public AER-1 kit repository.

Independent implementations and independent checks

Independent implementations are listed in the canonical AER-1 registry, which also records cross-system verification: one implementation checking another's receipts cold. Two checks on record show what that means in practice:

• A cold build from the text alone. An independent implementer built a conforming verifier using only the draft text, with no reference code, and reported three findings where the text and the required behavior diverged. The findings were folded into revision 21, with the implementer credited in the draft.
• An outside probe of a live receipt. An independent lab took a live AER-1 receipt it had never seen, ran its own probe checks against it with its own receipt tooling, and published a crosswalk between AER-1 and its own format, including where the two formats agree and where they stop. The full story: a stranger probed our receipt format cold.

That is the point of publishing a format instead of a feature: people the author does not control can build to it, test against it, and say in public whether it holds.

Looking for a different AER-1?

This page covers AER-1, the Agent Execution Receipt format for AI agent work. The same initials show up elsewhere: an Aer1 line of air purifier filters, several aircraft designations, and a rocket engine project. If you searched for an air filter, a plane, or an engine, this is not that page, but you are welcome to stay and see what an execution receipt is.

Related

• AER-1 deep dive: mechanics, conformance levels, interop
• What is a verifiable execution receipt? Definition and guide
• Verify an AER-1 receipt: step by step
• The AER-1 registry: implementations and cross-system verification
• A stranger probed AER-1 cold: WhiteMagic Labs, six checks, all pass
• draft-zambo-aer1-23 on the IETF Datatracker
• Verify a receipt right now