Axis one: what the receipt binds, and what it cannot prove
A receipt is worth what it binds. The strongest designs bind the recorded inputs under an input hash, the saved result under an output digest, the tool name, version, and scope, the execution timestamp, the provenance class that says who ran or reported the call, and, when the call is one step of a larger job, the receipt's position in the run's ordered step sequence. Weaker designs bind less: an output with no inputs can quietly migrate to a different request later, and a summary with no committed bytes binds nothing a receiver can test.
The other half of the axis is honesty about the ceiling. No binding, however complete, proves the result was correct, proves the agent picked the right tool, or proves an external event happened beyond what the record itself shows. A receipt is a commitment to a record, not a verdict on the world. Designs that blur this line are selling the blur.
Where AER-1 sits. AER-1 binds the recorded inputs, the saved result, the tool identity and scope, the timestamp, and the provenance class in every per-step receipt, and states the narrow claim in its own text: the receipt proves the saved result was not changed since it was saved. The attestation page walks the bindings one by one.
Axis two: recomputable hash chains vs signature-only envelopes
Signature-only designs ask you to trust a signer. An envelope carries a signature over the record, and checking it proves a key holder endorsed those bytes. If the receiver cannot reconstruct the digests independently, the verdict still rests on the signer's process, the signer's key custody, and the signer's honesty. The signature attests; it does not let you recompute.
Recomputable designs hand the verdict to the receiver. Digests are computed over the saved bytes by a published construction, and each step receipt folds into a root digest over the whole run. The receiver needs the record and the published rule, nothing else: no account, no key, no relationship with whoever ran the agent. Apply one test to any design on this axis: hand the record to a stranger. If the stranger can reach a verdict alone, the design is recomputable. If the verdict requires asking the issuer, it is signature trust with extra steps.
Where AER-1 sits. AER-1 receipts carry SHA-256 digests over the recorded inputs and the saved result, and a workflow record computes its root over the ordered step receipt identifiers by the rule published in Section 8.1 of the draft. Anyone can recompute every link. The audit trail page shows a root recomputed from live receipts, end to end.
Axis three: public verification off-chain vs on-chain anchoring claims
Anchoring proves a digest existed, and nothing more. Posting a hash to a chain establishes that the hash existed at a block time. It does not open the record, recompute its contents, or tell a receiver what the agent did. The record still has to live somewhere, be served to the receiver, and be checked somehow. When a design leads with its chain, ask what the chain entry lets a stranger check. If the answer is only that a hash existed, the receipt still owes all of its evidence to the record behind the hash.
Public off-chain verification answers the receiver directly. The record sits at a public URL, and a public verify service recomputes the digests in the open: the receiver pastes a receipt identifier and gets a verdict in seconds, free, with no wallet, no gas, and no chain dependency. The trust question collapses to arithmetic the receiver can also run by hand.
Where AER-1 sits. AER-1 records live off-chain at public URLs, checked by the public verifier at zambo.dev/verify and by the verify API, with no chain dependency. Anchoring can complement a recomputable record as a timestamp witness. On this map it is a complement, never a substitute.
Axis four: authorization records before the run, execution receipts after it
Two different moments produce two different records. Before execution, an authorization record captures that a person approved an action: who approved it, what scope they granted, what limits they set. After execution, a receipt captures what actually ran and what came back. The first record governs the mandate; the second governs the outcome.
They are complements, and accountability needs the pair. Approval without a receipt leaves the outcome on trust: the agent was allowed to act, and its report of what it did is taken on faith. A receipt without approval leaves the mandate undocumented: the work is checkable, and nobody recorded whether it was wanted. One asymmetry decides which half can stand alone as evidence: only the execution receipt can be recomputed, because only it commits to bytes the run itself produced.
Where AER-1 sits. AER-1 is the post-execution half. Its provenance class records who ran or reported each call, inside the committed record, and it composes with whatever approval process ran before the call rather than replacing it.
Axis five: an open format with a public conformance corpus vs a vendor backend
Vendor-backend designs make verification a service. The receipt is a row in the vendor's database, and checking it means asking the vendor's API whether the row is valid. The answer is only as independent as the vendor, and it lasts exactly as long as the vendor does. If the vendor disappears, the records stop verifying, however carefully they were made.
Open-format designs make verification a property of the record. The format is published where anyone can read it, and a public conformance corpus of test vectors lets any independent implementation check itself against the same cases the format's own tooling passes. Implementations can then check each other, and a record outlives any single operator.
Where AER-1 sits. AER-1 is published as an IETF Internet-Draft, draft-zambo-aer1-23, with a public conformance corpus of 119 test vectors and a live public verify service. The same receipt can be checked by the public verifier, by the verify API, or by an independent implementation running the corpus. Conformance results are published on the AER-1 implementation report.
The standards neighborhood: where AER-1 sits among the approaches
The axes above describe designs. Standards work clusters into families, and the family a format belongs to predicts most of its axis positions before you read a line of it. Three family questions place AER-1 among its neighbors: which moment the record covers, where the record's evidence lives, and what the record commits to.
Family one: the moment covered. One family of approaches standardizes the pre-execution half: authorization records that capture who approved an action, in what scope, under what limits, before anything runs. Another covers the post-execution half: records of what actually ran and what came back. AER-1 belongs to the post-execution family. The two are complements rather than rivals, and a complete accountability story usually wants both: the mandate recorded before, the outcome recomputable after. AER-1 composes with an authorization record instead of competing with it, and its provenance class records who ran or reported each call inside the committed record itself.
Family two: where the evidence lives. One family anchors records into a transparency log: entries are appended to an append-only public history, and inclusion proofs plus consistency proofs let third parties check that the history was not quietly rewritten. The evidence for any single record then lives partly in the log: its position, its witnesses, its continued availability. AER-1 sits in the self-contained family. The record carries its own digests over its own bytes, and verification runs from the record alone, with no log involved and no dependency on one. A log can still witness an AER-1 record as an extra timestamp, and the format does not forbid it. The difference is what verification needs: in the anchored family, the log; in AER-1, only arithmetic.
Family three: what the record commits to. One family issues attestations as credential-style claims: an identified issuer states metadata about an action, who, when, under what policy, and the trust rests on the issuer and its key. These records commit to claims about the work. AER-1 commits to the work itself: the recorded inputs under an input hash and the saved result under an output digest, so the receiver recomputes the payload rather than weighing the claim. A metadata-only record can be perfectly honest and still leave the central question, what did the call actually return, answered by assertion. A payload-committing record answers it with bytes.
Placed on those three questions, AER-1 is the post-execution, self-contained, payload-committing member of the neighborhood. Its bet is that the execution half had to exist first as an open, recomputable format, because it is the half every other record ultimately points at: an approval is only as good as the outcome it can be compared against, a log entry only as useful as the record it anchors, and a metadata claim only as strong as the payload it declines to bind. The definitional companion to this map is the execution receipt standard page, and the log side of the family is covered in the transparency log page.
One neighbor deserves naming, because it is the transparency family with an IETF working group behind it: SCITT, Supply Chain Integrity, Transparency, and Trust. SCITT standardizes the transparency service itself: signed statements are submitted to an append-only log, and the service returns an inclusion proof, which SCITT calls a receipt, showing the statement was registered. Note the word collision: a SCITT receipt proves a statement entered a log; an AER-1 receipt is the execution record itself, the inputs and the saved result of a tool call under digests. The two compose rather than compete. A transparency service can register or witness an AER-1 record, giving it a public position in a history; the AER-1 record gives the log an entry whose evidence is the payload, not a summary of it. And the dependency runs one way only: AER-1 verification needs no log, no service, and no SCITT deployment, which matters in the many settings where no transparency service exists yet.
How to place any receipt design on this map
Five questions, one per axis
1. What does it bind? Inputs, result, and provenance under digests, or a summary you have to take on faith?
2. Who can reach the verdict? A stranger with the record alone, or only the issuer and its key?
3. What does the chain entry actually prove? That a digest existed, or anything about the work itself?
4. Which moment does it cover? The approval before the run, the execution after it, or both halves of the pair?
5. What survives the vendor? If the operator shut down tomorrow, would the records still verify?
A design that answers all five cleanly is evidence. A design that dodges any of them is asking for trust at exactly that joint, and now you know where to press. The general method behind these questions is laid out in Verify AI work: check the record, not the summary.
The format this page is written against: AER-1
The receipts referenced across this hub follow one open format: AER-1, IETF Internet-Draft revision 23 (draft-zambo-aer1-23). AER-1 is an IETF Internet-Draft, not a finalized standard. It defines the per-step verifiable receipt and the workflow record that links the receipts of a run, so a receipt produced in one place can be checked by a receiver somewhere else, with no account on the system that produced it. The step-by-step checking method is on the receipt verifier page, and the category definition is on the execution receipt standard page.
To put receipts under your own agent's work: start with the live demo for a single checked call, then a Zambo Day Pass for a day of calls with a verifiable receipt under each one.
Questions, answered
What is an AI agent execution receipt?
An AI agent execution receipt is a record created when an AI agent runs a call, binding what ran to what came back: the recorded inputs, the saved result, the tool, and the provenance class, committed under digests a receiver can recompute. A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was correct, and it does not prove an external event happened beyond what the record itself shows.
What are the main design choices behind agent execution receipts?
Five choices define the landscape. First, what the receipt binds: inputs, result, and provenance, or only a summary. Second, how it is checked: recomputable hash chains a stranger can verify from the record alone, or signature-only envelopes whose force ends at the signer. Third, where verification lives: off-chain records with a public verify service, or on-chain anchoring that proves a digest existed without opening the record. Fourth, which moment it covers: authorization before the run or execution after it. Fifth, who can verify: anyone, against an open format with a public conformance corpus, or only the vendor, through its own backend.
What does an execution receipt prove, and what does it not prove?
A verifiable execution receipt proves the saved result was not changed since it was saved, and it lets anyone read that saved result and recompute its digest. It does not prove the result was correct, it does not prove the agent chose the right tool, and it does not prove an external event happened beyond what the record itself shows. Any receipt design claiming more than the first sentence is claiming something a record cannot do.
Is an on-chain execution receipt stronger than an off-chain one?
Not by itself. Anchoring a digest on a chain proves that digest existed at a block time. It does not open the record, recompute its contents, or tell a receiver what the agent did; the record still has to live somewhere and be checked somehow. An off-chain record whose digests anyone can recompute through a public verify service gives a stranger a verdict in seconds, with no wallet and no chain dependency. Anchoring can complement a recomputable record. It cannot substitute for one.
What is the difference between an authorization record and an execution receipt?
An authorization record is created before a run and captures that a person approved an action: who approved it, what scope, what limits. An execution receipt is created by the run itself and captures what actually ran and what came back. They are complements, not rivals: approval without a receipt leaves the outcome on trust, and a receipt without approval leaves the mandate undocumented. Only the execution receipt can be recomputed, because only it commits to bytes the run produced.
How does AER-1 relate to other receipt and transparency standards?
By neighborhood, on three axes. On timing, some designs in the neighborhood record authorization before a run; AER-1 records execution after it, and the two halves compose. On anchoring, some designs anchor records into a transparency log whose append-only history is part of the evidence; AER-1 records are self-contained, carrying their own digests and verifying with no log involved, though a log can witness one. On commitment depth, some designs commit to metadata only, who and when claims that do not bind the content; AER-1 commits to the payload itself, the recorded inputs and the saved result under digests a receiver recomputes. Same neighborhood, different joints, and the joints decide what a stranger can check.
Does AER-1 require a transparency log?
No. An AER-1 receipt verifies from the record alone: the digests over the recorded inputs and the saved result are in the record, and the construction for recomputing them is published in the draft. A transparency log can add a public timestamp witness for a record, and nothing in the format forbids anchoring one, but verification never depends on a log being available, honest, or still running. The record carries its own evidence.
Why does an open format matter for execution receipts?
If verification means asking the vendor's backend whether its own record is valid, the receipt's force ends at the vendor. An open format published for anyone to read, with a public conformance corpus of test vectors, lets independent implementations check the same records and check each other. AER-1 is published as an IETF Internet-Draft (draft-zambo-aer1-23) with a public conformance corpus and a live public verify service, so a receipt can be checked by the public verifier, by the verify API, or by an independent implementation running the same vectors.
How does AER-1 relate to SCITT and other transparency standards?
SCITT is the IETF working group on Supply Chain Integrity, Transparency, and Trust; it standardizes transparency services, where signed statements are registered in an append-only log and returned with an inclusion proof (which SCITT itself calls a receipt). AER-1 works one layer down: it defines the execution record, what an agent's tool call committed to and what it returned, verifiable from the record alone with no log involved. The two compose: a transparency service can register or witness an AER-1 record, and the AER-1 record gives the log payload-level evidence to anchor. AER-1 needs no SCITT service to verify, and SCITT does not define the execution record. Same neighborhood, different layer.