The AER-1 conformance test: 122 checks, run by anyone

The short answer

A note on names first, because this query collects collisions: this page is about the conformance suite for AER-1, the Agent Execution Receipt format published at the IETF (draft-zambo-aer1-23). Unrelated industries use similar initials for their own tests; none of those are this, and this is none of those.

Why a receipt format needs a test at all

A receipt is only useful if a stranger's checker reaches the same verdict as yours. Two implementations that disagree about one byte of the format disagree about every receipt that byte touches, and the disagreement stays invisible until the day a client checks work your system swears is verified and their system calls unverifiable. Interoperability cannot be asserted in a README. It has to be exercised, vector by vector, against cases designed to separate correct readings of the draft from plausible wrong ones.

That is what the corpus is for. Each vector is a small, complete scenario: the receipt bytes, the context a checker is given, and the verdict the draft requires. The suite is the draft rendered executable, so an argument about what the text means gets settled by running it.

What the 122 checks cover

• Digest recompute. The checker rebuilds the SHA-256 commitment from the receipt's canonical bytes and compares it with the hash the receipt carries. This is the foundation check: the saved result either still matches what was saved, or it does not.
• Canonical payload reconstruction. Starting from the stored output and the known call context, the checker must reproduce the exact canonical bytes. Byte order, spacing, and encoding are all pinned; a near miss is a miss.
• Alteration rejection. Flip a byte in the record and the verdict must flip with it. Vectors include altered outputs and altered metadata, so an implementation that waves through a changed record fails loudly.
• Id binding. The receipt id sits outside the committed payload, so a bare id proves nothing by itself. The checks cover the three honest outcomes: an id supplied independently and matching, an id resolved through the record with its digest compared, and an unbound id, which a conforming verifier must report as unverified rather than quietly trusting it. These rules were sharpened by an implementer's public control test and shipped in draft -21, then pinned harder in -22.
• Refusals and honest gaps. Some vectors exist to check what an implementation says when it cannot check: the answer must be a stated not-checked, never a silent pass. A receipt format survives on the precision of its refusals.

Run it yourself

1. Get the kit. The public repository is gitlab.com/rambozambodotdev/zambo; the aer-1 folder holds the draft, the vectors, the runners, and the implementation guide most builders start from. Starter kits exist across languages, so most implementations begin from working code rather than a blank file.
2. Run the corpus against your verifier. Each failing check reports its name and the expected verdict, which turns debugging into reading: the check that fails is the section of the draft to re-read.
3. Compare across runners. The kit cross-verifies its own independent runners against each other (52 comparisons, no disagreements at kit 1.5.6). If your verdicts match the corpus and the runners match each other, your implementation speaks the same language as the ecosystem.

And if building is not your job today, the single-receipt version of the same discipline is free: paste any receipt into zambo.dev/verify and watch the checks report one by one. Conformance is that experience, applied to a whole implementation at once.

A conformance-shaped check, worked on a live receipt

Take a real record: a delivery receipt from an independent verification service that ships AER-1 receipts with its work. Its verification reports the suite's core checks individually: the SHA-256 commitment passes, the canonical payload reconstruction passes, the provenance and metadata bindings pass, and issuer authentication is reported as not checked, openly, because nothing in the record authenticates its issuer.

The foundation check can be re-run by hand, which is the suite's whole philosophy. The receipt publishes its canonical bytes: 2,078 of them. Recompute their SHA-256 and you get 5f06acfbe2ff6254f7bd3a494ef9848551a0946a305d82c4ac9da410a07dd2a5, exactly the output hash the receipt commits to. That recompute was run independently for this page from the live record. Alter one byte before hashing and the outputs diverge, and a conforming checker says so. No account, no permission, no trust in this page required: that reproducibility is what the 122 checks exist to protect at scale.

Who has run it, and what their runs changed

The corpus is not a solo artifact. An independent validator, WhiteMagic Labs, runs its harness against the kit and is listed in draft -22's implementation status, with a public keyless verification endpoint anyone can test against; its harness caught a real defect (a nil-UUID case the reference accepted) that was fixed in the tooling and folded into the corpus. An independent agent cold-ran the full -22 corpus in October 2026 and reported all 116 checks passing. The id-binding vectors exist because an implementer published a control test swapping receipt ids in public; the draft's answer to his experiment is now the rule the suite enforces, and he is credited in the draft's acknowledgments.

That loop, outsiders attack the corpus, the corpus absorbs the attack, the next revision ships with credit, is the conformance story. The suite gets harder to pass in the ways that matter because people keep trying to break it in public.

What it costs

The kit, the corpus, and the runners are public and free, and checking receipts is free for anyone, forever, including the clients your work is done for. The receipts themselves are minted by the tools: work run through Zambo's 153 tools leaves one per job on the free tier on a normal day, a $0.99 Day Pass covers a heavy day of the full machine, and the $29 Pass ($19 for $ZAMBO holders, $290 for the year) fits agents that run daily. Start by checking something real: run the live demo and verify its receipt.