What is the agent execution receipt standard?

What the standard covers

AER-1 standardizes three things:

1. The receipt record. A JSON structure with five interoperable fields: identifier, creation time, tool and caller scope, canonical bytes of the observed result, and a SHA-256 output commitment.
2. The canonical-bytes rule. Producers must preserve the exact UTF-8 byte sequence that was hashed. Verifiers must reproduce those bytes exactly and reject anything that is not valid UTF-8. This is what makes independent verification possible.
3. The verification procedure. Take the canonical bytes, compute SHA-256, compare with the output commitment. Match means the stored result is the result the tool returned. Mismatch means tampering.

Everything else, field naming beyond the core five, transport, storage, display, is left to implementations. The standard pins down exactly the parts needed for cross-vendor verification and nothing more. A worked example of cross-vendor verification is the AER-1 x Tanilo interop: a full run with real Tanilo values, with the chain verified end to end.

Why a standard matters

Before a standard, every agent platform invented its own proof format, or had none at all. A receipt from one system could not be checked by anyone outside that system. That defeats the purpose: the whole point of a receipt is that the party being verified does not get to choose the verifier.

AER-1 makes receipts portable. A receipt produced by one implementation can be verified by any conformant verifier, including the public one at zambo.dev/verify. The checking party never needs an account with the producing party.

Status: IETF Internet-Draft

Implementations

Open implementations exist in multiple languages, and framework packages emit AER-1 receipts natively for popular agent frameworks. Because the verification procedure is fully specified, anyone can write a verifier in any language and check any conformant receipt.

The full record is published as the AER-1 Implementation Report: the independent implementations, the conformance results, and the independent verifications, all in one place.

For developers: pip install aer1-llamaindex adds receipt collection to LlamaIndex agents. Similar packages cover other major frameworks. Every run emits hash-chained, offline-verifiable receipts per the standard.

What the standard does not cover

AER-1 standardizes proof of execution, not proof of correctness. A conformant receipt proves the saved result was not changed. It does not prove the model was right, the tool was the right one to call, or the outcome was desirable. Authorization, policy compliance, and input integrity are separate layers that sit on top of the receipt format.

This boundary is deliberate. It is what keeps verification checkable by anyone, because checking correctness would require trusting someone's judgment.

AI agent receipt schema

The schema is the receipt, written down. The AI agent receipt schema is the field-level definition of a verifiable execution receipt: the identifier, the timestamps, the tool and caller scope, the saved result, the digest committed over that result, and the provenance class that says who ran or reported the action. AER-1 defines the schema as an open IETF Internet-Draft (revision 23, draft-zambo-aer1-23), with a public conformance kit of test vectors so an implementation can prove it produces and checks the same object the schema describes.

Zambo is the verifiable work layer for AI, and its hosted receipts follow the schema on every call; the verify endpoint returns the receipt's fields so a checker can recompute the digest from the published bytes rather than trusting a status flag. A schema matters because verification is only portable when every implementation agrees on what the record is.