What execution evidence actually is
When an AI agent runs, it calls tools, reads data, and produces outputs. Execution evidence is the record that this happened, built so that three things hold:
- It is captured automatically, at execution time. Not reconstructed after the fact, not exported on request. The receipt is minted as the work runs.
- It is tamper-evident. The record's bytes are committed to a SHA-256 hash. Change one byte and the recomputed hash no longer matches, so any edit after the fact is detectable by anyone holding the receipt.
- It is checkable by a stranger. A third party, an auditor, a customer, a court, can verify the record with the public verification algorithm, without an account, without asking the operator for permission, and without trusting the operator.
A verifiable receipt is the unit of execution evidence: one receipt per unit of work, hash-chained so the sequence is fixed, with a provenance binding that says who issued it. That is what the open standard AER-1 defines, as an IETF Internet-Draft (draft-zambo-aer1-23).
Open vs proprietary: why the standard matters more than the vendor
Every platform that runs agents can produce some record of what ran. The fork in the road is who controls that record's meaning. Proprietary proof keeps the format, the verification logic, and the trust root inside one vendor. An open standard publishes all three. Here is what that difference buys you:
| Property | Proprietary proof | Open standard (AER-1) |
|---|---|---|
| Record format | Defined by the vendor, changeable without your consent | Published in an IETF Internet-Draft anyone can read |
| Verification | Requires the vendor's SDK, API, or dashboard | Public algorithm; verify offline, no account, no permission |
| Who can implement it | Only the vendor | Anyone; independent implementations already exist |
| Evidence lifetime | Degrades if the vendor pivots, sunsets, or disputes your reading | Survives vendor churn; the text and the test suite are public |
| Auditor trust | Rests on trusting the vendor | Rests on math the auditor can re-run themselves |
The core argument is simple: evidence you cannot verify without the vendor's permission is not evidence, it is testimony. Auditors, enterprise buyers, and regulators prefer records whose integrity they can confirm themselves. An open standard gives them that; a proprietary format asks them to take the vendor's word for it.
The proof is already live: independent formats, one verifiable chain
Open standards are easy to announce and hard to demonstrate. So here is a live demonstration, not a roadmap. An AER-1 interop example shows an AER-1 execution receipt carrying a hash-committed reference to an independent receipt format's record: the AER-1 receipt commits to the exact canonical bytes of the other receipt via SHA-256, so a verifier can check both ends and confirm the chain.
What this proves matters more than the example itself:
- Receipts from different systems can reference each other verifiably. The reference is a hash commitment, not a hyperlink; if the referenced record changes, the mismatch is detectable.
- No shared infrastructure is required. The AER-1 receipt verifies on its own; the cross-reference is upside, never a dependency.
- This is how open ecosystems grow. Independent builders adopt the open format, extend it with their own evidence references, and every new implementation makes the whole graph of evidence more checkable.
A proprietary announcement has a slide deck. An open standard has a repo, a test suite, and someone else's implementation referencing yours. Browse the public registry of AER-1 implementations to see the ecosystem as it stands. For a single receipt you can check right now, open receipt 588f5158-e335-4ba8-9009-72fad8410d55 and recompute its digest.
The December 2026 clock
There is a calendar reason to care about this now. Under the EU AI Act, Article 50 transparency obligations have applied since 2 August 2026, and AI systems placed on the market before that date have a transitional window through 2 December 2026 to meet the Article 50(2) machine-readable marking obligations for AI-generated content. That is the last major AI Act milestone of 2026, and compliance teams are building their evidence packages right now.
Execution evidence fits that work in two places. First, Article 12 record-keeping requires high-risk AI systems to allow the automatic, tamper-evident recording of events: that is the logging limb of compliance, and verifiable receipts are exactly that layer. Second, every transparency disclosure is stronger backed by a tamper-evident activity record than by a plain log file. A compliance file that an auditor can re-verify without trusting the operator is a compliance file that holds up.
The teams that start generating tamper-evident records now will have a history to show when the deadlines bite. The teams that wait will be reconstructing one.
What the open path looks like in practice
Starting is deliberately boring, which is the point of a standard:
- Mint receipts automatically.
pip install aer1kitfor Python, or theaer-1package on npm for JavaScript and TypeScript. Framework collectors exist for SmolAgents, CrewAI, LangGraph, AutoGen, OpenAI Agents, and more. Every tool call produces a checkable receipt with no new infrastructure. - Verify anything, no account. Paste any receipt into the public verifier and see the check run in the browser. The verification algorithm is the same one in the draft text.
- Read the draft. draft-zambo-aer1-23 on the IETF Datatracker. It is an Internet-Draft, not a finalized standard, and the text is the ground truth for what a receipt must contain.
- Implement it yourself. The conformance kit and suite are public. Independent implementations are how a draft becomes a standard in practice.
If you run agents through an execution layer, the receipts can be minted for you automatically: every run provable, every receipt checkable, no code changes. The standard is the same either way, which is what makes it a standard.
Common questions
Does a verifiable receipt prove the agent did the right thing?
No. It proves the saved record of what ran was not changed afterward. Correctness, fairness, and judgment are separate questions that no receipt format can answer. What the receipt gives you is a trustworthy foundation those questions can be asked against.
Can proprietary proof formats be converted to the open standard?
The formats record different things under different trust assumptions, so conversion is really re-minting: take the execution data and issue an AER-1 receipt over it. Because the standard is open, nothing stops a vendor from emitting AER-1 receipts alongside their own format. Some already do.
What happens to my evidence if the standard changes?
Drafts evolve, but published receipts carry their version, and the verification algorithm for each version stays public. Old receipts remain checkable under the rules they were minted with. That is another property proprietary formats cannot promise without the vendor's ongoing cooperation.