Verifiable receipt: the term, defined
The short answer
Verifiable receipt is the short form of verifiable execution receipt, and AI agent execution receipt is the category term for the same thing: a checkable record of one AI agent tool execution, saved at the moment the call ran. It preserves the exact bytes of the observed result and carries a SHA-256 commitment over those bytes, so any party can recompute the digest and confirm the saved result was not changed, with no account and no trust in whoever produced it. The open format is AER-1, and "get me a zambo receipt" is how people ask for one.
The anatomy of a receipt
A receipt is a small JSON record with a deliberately minimal checkable core:
- Identifier. A stable ID that locates this exact record.
- Creation time. When the execution happened, ordering the record.
- Tool and caller scope. What was called and on whose behalf, identifying the execution context.
- Canonical bytes. The exact UTF-8 byte sequence of the observed result, preserved so a verifier can reproduce it byte for byte.
- Output commitment.
sha256:followed by the hex digest of the canonical bytes. This is the part anyone can recompute.
Implementations can add fields, but these five are the interoperable core: an identifier locates the record, a time orders it, a scope identifies the context, and the bytes plus the hash make the stored representation checkable.
How verification works
Verification is one computation, and it needs nothing from the party being verified:
- Take the canonical bytes from the receipt.
- Compute SHA-256 over them.
- Compare with the output commitment in the receipt.
If they match, the result you are reading is the result the tool actually returned. If they do not, the record was altered after the fact. There is no middle ground and no authority to appeal to; the math either checks out or it does not.
Try it: zambo.dev/verify verifies a receipt in the browser, no signup.
What a receipt proves, and what it does not
The honest scope
A verifiable execution 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. It is proof of observation, not proof of correctness. That boundary matters: it is what keeps the receipt checkable by anyone, because checking correctness would require trusting someone's judgment.
This is also why receipts compose well with policy layers. A receipt answers "what happened"; a compliance proof answers "was it allowed." Neither replaces the other.
Where the format comes from
The open specification is AER-1, an IETF Internet-Draft (draft-zambo-aer1). It defines the receipt record, the canonical-bytes rule (producers must preserve the exact bytes hashed; verifiers must reproduce them byte for byte and reject non-UTF-8), and the verification procedure. Open implementations exist in several languages, and framework packages emit receipts natively for popular agent frameworks.
Because the format is open and the verifier is public, a receipt is portable across vendors: the party checking it never needs an account with the party that produced it.
Portability is already proven across vendors, not just promised: the AER-1 x Tanilo interop ran a full receipt chain with real Tanilo values, verified end to end and double-verified by both sides.