AER-1: the open draft for portable execution receipts

AER-1 (AI Agent Execution Receipt), is the open draft spec for portable, verifiable execution receipts for AI agents. It defines the receipt vocabulary, canonical bytes, and independent verification, so any agent's work can be checked by anyone, anywhere.

Abstract

An AI agent execution receipt is a public, persistent, independently checkable record of one specific agent tool call. It identifies the execution, records when it happened, preserves the canonical bytes used for the output commitment, names the tool and caller scope, and exposes the observed result through a stable public URL.

The receipt answers a narrow question: what did this system record for this execution? It does not prove an external business outcome that the system did not observe, and it does not turn a planned, blocked, or preview action into a completed execution.

IETF Datatracker listing

AER-1 is an open draft spec for AI work receipts.

Whole-job provenance classes

A whole job can combine actions performed by Zambo, actions observed through a gateway, and actions reported by another agent. Every timeline entry must name exactly one provenance class so verification never upgrades a report into an observation.

Entries for one job form an append-only hash chain. A public /run/<job-id> or /run/<entry-id> page resolves the whole timeline and reports whether that visible chain verifies.

Core vocabulary

Schema-valid minimal receipt shape

This illustrative raw _receipt object is not a live receipt. It matches the transport fields in the current JSON Schema. The Base64 value e30= decodes to {}, and the shown digest is SHA-256 of those exact two bytes.

{
  "id": "00000000-0000-4000-8000-000000000001",
  "tool": "example_tool",
  "timestamp": "2026-10-04T12:00:00Z",
  "receipt_schema_version": "0.3",
  "tool_context": { "name": "example_tool", "version": "example", "scope": "public" },
  "provenance_class": "EXECUTED BY ZAMBO",
  "canonical_bytes": "e30=",
  "canonical_byte_length": 2,
  "hash_algorithm": "sha256",
  "output_hash": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
  "verification_status": "execution_observed",
  "status": "success"
}

This object demonstrates the raw schema shape and a matching byte hash only. It does not represent an execution or a public receipt.

Verification procedure

1. Resolve the public receipt URL and confirm the receipt ID matches the requested execution.
2. Read the exact canonical bytes or the representation needed to reproduce them.
3. Compute SHA-256 over those bytes and compare it with output_hash.
4. Review the tool, timestamp, caller scope, observed result, evidence, and anchor status separately.
5. Report only what the stored observation supports.

RECEIPT_ID="36a16e13-8612-4c90-a807-41c77bbe1b79"
curl -fsSL "https://zambo.dev/api/receipt/$RECEIPT_ID/verify" \
  | jq -e '{id, verification_status, output_hash} | select(.verification_status == "verified")'

curl -fsSL -X POST https://zambo.dev/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"zambo_universal","arguments":{"need":"What is the current price of Bitcoin in USD?"}}}'

Design rationale

AER-1 starts with a narrow record rather than a universal theory of agent behavior. An agent may call several tools, receive information from several providers, and hand work to another agent. A reviewer still needs a stable way to identify one execution, understand what the system observed, and check whether the published bytes match the stated commitment. The draft keeps those needs separate from claims about the outside world.

The vocabulary is intentionally small because interoperability fails when every implementation gives a different name to the same boundary. An identifier locates the record. A creation time orders it. A tool and caller scope identify the execution context. Canonical bytes and an output hash make the stored representation checkable. A result preview gives a human a useful first read without pretending that a preview is the entire source dataset.

Provenance is a separate design axis. A system can execute a tool itself, observe an action through an integrated gateway, or receive a report from another agent. Those cases can all be useful, but they do not support the same statement. AER-1 therefore treats provenance as part of the record rather than as a marketing label. A verifier should be able to tell which party performed the action and which party only recorded the report.

The draft also treats failure as a first-class outcome. A malformed request, unavailable provider, blocked permission, or waiting access step still has a useful execution boundary. Erasing that boundary and returning a successful-looking summary makes later review harder. A compatible implementation should preserve status and explain the recovery path when the work did not complete.

Field walkthrough with a live receipt

Use a public receipt such as the live live_price example above as the running case. First resolve its UUID and confirm that the public page, API response, and verifier request all use the same value. This protects against a common review error: copying a result from one record while checking the integrity state of another record.

Next inspect created_at, tool, and caller. The time tells you when the receipt store created the record. The tool tells you which capability crossed the execution boundary. Caller and session fields provide context when they are included. None of these fields alone proves that the returned market data was correct. They identify the record and its context so that the evidence can be evaluated at the right boundary.

Inspect job_summary, steps, and result_preview next. For a single tool call, the step list should show the tool and its recorded status. For a whole job, the list can explain the sequence without requiring a reviewer to reconstruct the original chat. A preview helps a person decide what to inspect, but it must not be treated as a complete copy of every upstream response or as a replacement for source evidence.

The integrity check uses canonical_bytes, canonical_byte_length, output_hash, and hash_algorithm. Fetch the representation that the implementation exposes, compute the declared digest over the exact bytes, and compare the result. If the bytes or algorithm are unavailable, report that verification is unavailable. Do not silently substitute a different serialization, whitespace policy, or JSON key order and call the result verified.

Evidence and provenance complete the review. Evidence fields identify an upstream source when the tool captured one, while provenance fields explain whether Zambo executed, observed, or logged the action. Anchor and check fields expose additional state when the record contains it. A valid integrity check means the stored bytes are stable. It does not mean that an external provider was accurate, that a trade settled, or that a business outcome occurred.

The running example therefore supports a precise statement: the named tool ran or was recorded at the stated time, the receipt store returned the stated result, and the public record can be checked through its verification path. It does not support a broader statement about every market, account, or external event. AER-1 is useful when that distinction is visible to the next reviewer.

Conformance notes

A conforming implementation should make the receipt identity stable, expose the schema version, preserve the exact bytes used for the output commitment, and state which hash algorithm produced the digest. It should return a clear status when required data is missing. It should not report a receipt as verified merely because a database row exists or because an agent supplied a confident summary.

Conformance also includes the negative space around the record. The implementation should distinguish an attempted action from a completed action, and an observed result from an assertion about the outside world. If a gateway only received a report, the receipt should say that it logged the report. If a provider was unavailable, the status should remain unavailable. If a human approval is required, the receipt should expose the waiting boundary rather than implying authorization.

Interoperability testing should use fixed examples and failure cases. A test vector can include a known UUID, canonical byte sequence, hash, expected status, and provenance class. The verifier can then check the positive case, a changed byte, a changed algorithm, a missing field, and a mismatched identifier. Public test vectors are valuable because another implementation can reproduce the checks without access to the original database.

Version compatibility requires care when fields are added. New optional fields should not change the meaning of existing identity or integrity fields. A verifier that cannot interpret a required version should fail clearly and preserve the distinction between unsupported and invalid. An old receipt should remain inspectable when the implementation can still interpret its schema, while a changed storage representation should not be presented as the original canonical bytes.

AER-1 is an open draft spec for AI work receipts.

Versioning and compatibility

Implementations should identify their receipt schema version and keep old receipts verifiable when the storage format evolves. A verifier should fail clearly when required bytes or metadata are unavailable rather than silently treating an incomplete record as verified.

FAQ

How to cite this page

@misc{zambo_aer1,
  author = {Zambo},
  title = {AER-1: AI Agent Execution Receipt},
  year = {2026},
  url = {https://zambo.dev/aer-1},
  note = {Open draft, accessed 2026-10-05}
}

To try the live reference implementation, install the Zambo MCP connection. If you need 24 hours of listed access after choosing a workflow, the $0.99 USDC on Base Day Pass starts from the moment it is activated.

Related citation articles

AI agent audit trail · Tools that prove what an AI agent did · Verifiable receipt for AI tool calls · AI agent hallucinated completion · AI agent accountability · My AI agent said the task was done, but nothing happened · Verify the AER-1 open draft spec receipt fields

Compliance and audit guides

AER-1 records execution evidence; these guides explain related review and compliance contexts. AI audit trail evidence and compliance review · How to prove what an AI agent did · EU AI Act evidence and AI execution records