The conformance kit
Conformance is tested against vectors derived from the draft text, run by two independent reference runners that must agree on every vector: conformance.py (Python, standard library only) and conformance.js (Node, standard library only). The corpus counts below are the kit's own recorded counts (kit README changelog, v1.5.2, 2026-10-13), recounted from the tree:
- 99 vectors in total: 44 test-vector files (9 valid, 28 invalid, 1 invalid-profile, 6 anchored), plus 28 chain vectors (v07) and 7 chain vectors, 8 commitment vectors, 9 Merkle vectors, and 3 Unicode vectors.
- 102 checks per runner: the Merkle corpus yields three additional workflow-verdict checks beyond its 9 vectors.
- Cross-verification: the two runners are cross-checked over the 44 core vectors with 0 disagreements; the kit's conformance record shows every fixture passing on both runners with agreement on each row.
How the corpus tests an implementation:
- Valid vectors are receipts that MUST verify, including a real receipt issued by the reference implementation and a receipt carrying every optional member added by draft -18.
- Negative vectors each isolate exactly one broken rule: a missing member, a hash mismatch, a duplicate member name, a leap-second timestamp, a non-UTF-8 canonical byte string, an
input_hashthat is the digest of different inputs than the payload records, and so on. A verifier must reject each one for the stated reason, not just fail it. - Profile vectors pin the boundary between the core check and the stricter reference-producer profile: a receipt that omits the
inputsmember is core-valid but MUST fail the profile check. - Chain vectors cover the Section 7 chain construction: valid timelines plus relabel, insert, delete, and splice attacks, genesis rules, and
seqrules. - Merkle vectors cover the Section 8.1 construction: leaf and internal-node construction, odd-node duplication, ordering, the duplicate receipt-id collision, and the one-step case, where a workflow with a single step receipt has that receipt's leaf digest as its root.
- Anchored fixtures cover the optional disinterested tier, including an anchor whose log reference cannot be resolved: the per-anchor outcome is reported alongside the commitment check, never collapsed into it.
Run it yourself: python3 aer-1/conformance.py or node aer-1/conformance.js. Exit 0 means every valid vector verified, every invalid vector was rejected for the right reason, and every profile-boundary vector landed on the correct side of the boundary.
Independent implementations
The status words are the records' own words. Conformant means the implementation passed the conformance vectors named in its recorded result. Parity-checked means the implementation was compared against its author's own verifier logic in large comparison runs: parity comparisons, not runs of the conformance kit. This report keeps that distinction visible instead of upgrading the claim.
| Implementation | Implementer | Language / runtime | Draft revision tested | Recorded result | Status |
|---|---|---|---|---|---|
| ARION's AER-1 verifier | ARION | Node.js (stdlib-only) | draft-zambo-aer1-08 | 165/165 (full suite) | conformant |
| ARION's AER-1 Java verifier | ARION | Java 11+ | draft-zambo-aer1-10 | 186/186 | conformant |
| aer1-perl | ColonistOne | Perl (core modules only) | draft-zambo-aer1-09 | 68/68, zero disagreements against the Python and Node reference runners | conformant |
| MasterD AER-1 verifier | MasterD (Arkie AI) | Python (stdlib only) | not recorded | 84/84 | conformant |
| ARION's AER-1 Ruby verifier | ARION | Ruby | not recorded | 24,834/24,834 parity comparisons, 0 divergences | parity-checked |
| ARION's AER-1 Swift verifier | ARION | Swift | not recorded | 19,615/19,615 parity comparisons, 0 divergences | parity-checked |
| ARION's AER-1 PHP verifier | ARION | PHP | not recorded | 11,529 runs, 0 verdict divergences | parity-checked |
Source records: implementations.json in the kit (updated 2026-10-03) and the external entries of registry.json (updated 2026-10-08). ARION's Node.js verifier was written from the draft -08 text alone, with no kit access; the record notes it was independently reproduced twice against the reference kit. The MasterD verifier's registry record describes it as a clean-room implementation from the draft text. The Perl verifier's record notes three spec findings it filed that were adopted by draft -10. The same registry also records the kit's bundled ports (Rust, Go, TypeScript, Python, Java, C#, Swift) at 45/45 each against the frozen v1.3.2 corpus of 45 vectors.
Independent verifications
Beyond implementations, outside parties have recomputed the draft's constructions from the text and run the cross-format interop cases. Each result below is reproduced as recorded.
Cairn Commons: the draft's math, recomputed from scratch
On 2026-10-09, Cairn Commons published an independent verification of draft-zambo-aer1-14. Their method: their own Python script using only hashlib, run in locked-down Docker containers with no network access, recomputing the draft's example values from the spec text rather than from any AER-1 code. The workflow Merkle root matched (7c4817ca...f63b37), the example receipt's output hash matched (0492c18e...12b9f1), and the odd-level duplicate collision was confirmed real for 3 and 5 steps, across three independent test runs, all reproduced. They published their full script and Dockerfile so anyone can re-run the verification. On 2026-10-11, three further independent testers re-ran their own verification against the post and reproduced the results. Record: the Cairn Commons verification post.
Tanilo: the two-party chain run
On 2026-10-08, the AER-1 x Tanilo interop chain was verified end to end, each receipt checked under its own rules. The chain run by Joe Krausz (Tanilo): aer1_verify.py on the AER-1 example PASS, 15/15. The interop receipt is anchored on GOAT mainnet, block 15948054. Records: the Tanilo interop page and the kit record.
FlyThink: physical completion claims
On 2026-10-08, the AER-1 x FlyThink interop fixture replayed 4/4 cases PASS, including the case where a valid AER-1 receipt coexists with invalid physical evidence binding: binding never causes claim inheritance. Record: the FlyThink interop page.
Iman Schrock: a divergence found, fixed, and rechecked
On 2026-10-12, Iman Schrock (Emilia Protocol) reported that Sections 8.5 and 8.7 of the draft described the workflow merkle_root over step output hashes, where normative Section 8.1 specifies step receipt identifiers: two different roots for the same workflow. The report was correct. Draft-zambo-aer1-19 aligned the Section 8.5 and 8.7 descriptions to Section 8.1 (a documentation alignment; Sections 8.1, 8.2, and 8.6 are byte-identical to revision 18, and no construction, field, digest, or verification rule changed), the conformance corpus gained the one-step test vector he requested, and the production server aligned to Section 8.1 the same day. Draft -19 credits him in its acknowledgments. On 2026-10-13 he rechecked the API himself and confirmed in writing that the live root now matches the corpus vector, closing the report. The full three-way agreement is worked line by line on the interop results page.
Production implementation
The reference implementation runs in production at zambo.dev. Its MCP endpoint is https://zambo.dev/mcp, and calls through the hosted service mint AER-1 receipts. One of those live receipts is in the conformance corpus itself (receipt-03-live.json), verified byte for byte, so the kit tests the production output and not only synthetic fixtures.
For multi-step work, each step leaves its own receipt, and the job closes with a summary receipt that binds the step receipts together under a single root digest computed per Section 8.1: the leaf is the SHA-256 digest of the step receipt identifier's UTF-8 bytes, internal nodes hash the concatenated raw digests, and an odd level duplicates its last digest. Change one step after the fact and the root no longer matches.
The one-step case is the worked proof. Workflow 6b6952a5-ab1f-4596-a0b3-a352c137cb41 has one step, receipt 4028dabb-3d12-4960-855c-639ce37f14cc, and three independent computations of its root agree on the same value: the spec computation from the draft text, the corpus vector's expected_root, and the merkle_root the hosted server returns for the workflow all equal 7c90f65aeccd214f8bb583bec76878d5f463d65b9b26c11e07c51dd59be814d5. Recompute the spec side yourself in one line:
printf '%s' '4028dabb-3d12-4960-855c-639ce37f14cc' | sha256sum 7c90f65aeccd214f8bb583bec76878d5f463d65b9b26c11e07c51dd59be814d5
How to be listed
- Implement it: the kit repo is gitlab.com/rambozambodotdev/zambo; start with IMPLEMENTING.md and run your implementation against the corpus in
aer-1/. - Get listed: implementations with recorded results are listed in the public registry of AER-1 implementations, with the machine-readable data at registry.json. The registry records results as reported and reproduced; parity results are listed as parity, never upgraded.
- The draft: draft-zambo-aer1-23 on Datatracker (full text at the IETF archive).
- Verify a receipt: how to verify an AER-1 receipt, or the hosted checker at zambo.dev/verify.
See it live: zambo.dev/demo mints a verifiable receipt in about 10 seconds, no signup. Keep the receipt link and share it where the work gets reviewed. For a full day of receipt coverage, see the Day Pass.