AER-1 / AI AGENT EXECUTION RECEIPT

The open draft for portable execution receipts.

Open draft/RFC — a proposal, not a finalized standard

AER-1 describes a small vocabulary for recording one AI agent execution so another person or agent can inspect the same record later. It is an open proposal authored by Brennan Zambo, not a claim to invent or own the broader execution-receipt category.

Status and scope

AER-1 is an open draft/RFC. It is intended for discussion, implementation experiments, and interoperability feedback. It does not establish certification, registry membership, universal adoption, or a finalized standards status.

Canonical home: https://zambo.dev/aer-1 · Implementation: the live Zambo MCP and public /run/<uuid> receipt pages.

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.

Core vocabulary

Receipt

A public record for one execution with a stable UUID, execution metadata, canonical bytes, and an output commitment.

Canonical bytes

The exact UTF-8 byte sequence used for the output hash. Verifiers must receive or reproduce the same bytes before comparing hashes.

Observed result

The result the implementation received and stored. A receipt reports observation, not an unsupported claim about the world.

Evidence

When upstream data was captured, the receipt can identify its source, request parameters, capture time, byte length, and evidence hash.

Minimal receipt shape

This is the smallest useful interoperable shape. Implementations may add fields, but additions should not make the core identity or verification fields ambiguous.

{
  "receipt_id": "UUID",
  "receipt_schema_version": "0.3",
  "created_at": "2026-09-22T00:00:00.000Z",
  "tool": {
    "name": "example_tool",
    "version": "4.0.0",
    "scope": "public"
  },
  "canonical_bytes": "<base64 of exact UTF-8 bytes>",
  "output_hash": "sha256:<digest of canonical bytes>",
  "verification_status": "verified",
  "public_url": "https://example.test/run/<receipt_id>"
}

The template is illustrative. The examples below are live records from the Zambo receipt store, not template data.

Verification procedure

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

Copy-paste verification using the existing verifier core

This calls the live verifier for a real public receipt and exits nonzero if it is not verified.

RECEIPT_ID="05c37cbd-0064-4d49-a3ad-055013157229"
curl -fsSL "https://zambo.dev/api/receipt/$RECEIPT_ID/verify" \
  | jq -e '{id, verification_status, output_hash} | select(.verification_status == "verified")'

Direct verifier: open the JSON result →

Live reference implementation

Zambo exposes the receipt contract through one MCP endpoint and gives successful calls a public /run/<uuid> page. These are two independent live records that can be opened and verified without a wallet or token.

live_price

Open receipt 05c37cbd →

Output hash: sha256:0f2e1a26239ff6f1c1e7909fb94eeaec063bdb19d4c1fe3e6887dbf86765e741

capability_search

Open receipt 071c7761 →

Output hash: sha256:02e47df48bbaeb2dded30eb212ec09be4d34a69d29dd063af047730176ea0945

curl -fsSL -X POST https://zambo.dev/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"live_price","arguments":{"symbol":"BTC"}}}'

The response contains the receipt identity and public verification link. The MCP endpoint is the live reference implementation of this draft's execution-record vocabulary.

Privacy and security considerations

Receipts should not publish credentials, private prompts, private contact details, or upstream response bodies that contain secrets. Public projections should redact sensitive fields while keeping the commitment and verification contract honest. Evidence hashes should remain distinct from transformed output hashes.

Integrity is not correctness. A valid hash shows that the stored canonical bytes match the stated commitment; it does not independently establish that an external provider's data was true or that a business outcome occurred.

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.

How to cite AER-1

Suggested citation: Brennan Zambo, “AER-1: AI Agent Execution Receipt,” open draft/RFC, https://zambo.dev/aer-1, accessed 2026-09-22.

Use the access date for a web citation. This page may change while the proposal is discussed; do not cite it as a finalized standard.

Relationship to other work

AER-1 is an independent open proposal. draft-xkumakichi-xaip-receipts-03 is an Independent Submission, an individual draft, and Informational. It is not WG-adopted and expires 2027-01-03. AER-1 does not evaluate or disparage that work; the drafts have different authorship and histories, and readers should consult each document directly.

Define and verify a receipt → Read the receipt guide → Browse live receipts → Author and attribution →