Direct answer

AER-1 Draft -21 Changelog: Receipt-ID Binding

Draft -21 of AER-1, posted October 17, 2026, answers one sharp question: when does a receipt id actually prove it belongs to the record it labels? The answer the draft now states plainly is that the receipt id sits outside the committed payload, so a bare id binds to nothing by itself. An id counts as bound only when it arrives through one of two doors: an externally supplied expected id, or Section 9 resolution with digest comparison. Everywhere else, a verifier must report the id as unverified.

Read the current text at draft-zambo-aer1 on the IETF Datatracker. Run conformance check 10 from the AER-1 kit repository, and check any single receipt free at zambo.dev/verify, no signup.

Updated October 20, 2026.

The binding rule, stated plainly

The committed payload of a receipt is what its output hash covers. The receipt id is not inside that payload. That design keeps ids usable as locators, but it has a consequence draft -21 makes explicit: presenting a record next to an id does not prove the id belongs to that record. A verifier that quietly trusts the pairing would let a swapped label pass as a verified receipt, and the whole point of the format is that labels are not evidence.

The two ways an id binds

First, an externally supplied expected id: the checker is told, from outside the record, which id this receipt is supposed to carry, and compares. In aer1-verify this is check 10, run with --expected-id. Second, Section 9 resolution with digest comparison: the id is resolved to a record and the resolved record digest is compared, run with --resolved-record. In both cases the binding evidence comes from outside the presented record itself. In every other case, aer1-verify 0.2.7 and later report the state in a machine-visible field, id_state, and an unbound id is reported as unverified.

aer1-verify receipt.json --expected-id <the-id-you-were-given>

aer1-verify receipt.json --resolved-record <the-resolved-record>

Credit and kit

Gigawatt is credited in Section 18 of the draft for the finding path behind this clarification. The kit for -21 is version 1.5.4, with 107 test vectors exercised as 110 checks. The id-binding vectors in that corpus cover the three honest outcomes: an id supplied independently and matching, an id resolved with its digest compared, and an unbound id that must be reported as unverified.

What implementers must do

Update any verifier that treats a presented id as self-proving. Add the two binding paths, expected id and resolved record with digest comparison, and report id_state so calling code can see the state instead of guessing from a pass or fail. Report an unbound id as unverified even when every other check on the record passes: the record can be intact while its label is unproven, and the report has to say exactly that. Then run the current kit, 119 vectors and 122 checks at kit 1.5.6 against draft -24, because the -21 rule still applies in the current text.

Cite this draft

Cite AER-1 as the IETF Internet-Draft draft-zambo-aer1, current revision -24, posted October 20, 2026 and expiring April 23, 2027, at datatracker.ietf.org/doc/draft-zambo-aer1.

@misc{zambo-aer1,
  author = {Brennan Zambo},
  title = {AER-1: Agent Execution Receipt, version 1},
  howpublished = {IETF Internet-Draft draft-zambo-aer1-24},
  year = {2026},
  url = {https://datatracker.ietf.org/doc/draft-zambo-aer1/}
}

Honest limits

Draft -21 is a historical revision, superseded by -22, then -23 on October 19, 2026, and then -24 on October 20, 2026, so implement against -24 and use this page to understand the binding rule it carries forward. The rule also has a hard edge: no local check on a single presented record can bind its id, because the evidence has to come from outside that record. And the standing limit applies: a receipt proves the saved result was not changed after the fact, never that the work was correct.

Frequently asked questions

What changed in AER-1 draft -21?

Draft -21, posted October 17, 2026, clarifies receipt-id binding. The receipt id sits outside the committed payload, so an id binds only via an externally supplied expected id or via Section 9 resolution with digest comparison. A verifier must report an unbound id as unverified. The kit moved to version 1.5.4 with 107 vectors and 110 checks, and Gigawatt is credited in Section 18.

Why does a bare receipt id prove nothing by itself?

Because the receipt id sits outside the committed payload that the output hash covers. Presenting a record next to an id does not prove the id belongs to that record. The binding evidence has to come from outside the presented record: an expected id supplied independently, or a resolved record whose digest is compared under Section 9.

What is conformance check 10 in aer1-verify?

Check 10 is the id-binding check added in aer1-verify 0.2.7. It runs with --expected-id for an externally supplied expected id, or --resolved-record for Section 9 resolution with digest comparison. The result is reported in a machine-visible field called id_state, so calling code can see whether the id is bound or unbound.

What must a verifier do with an unbound receipt id?

Report it as unverified, even when every other check on the record passes. The record can be intact while its label is unproven, and the report has to say exactly that. Quietly trusting a presented id would let a swapped label pass as a verified receipt, which is the failure draft -21 exists to prevent.

Does draft -21 change what an AER-1 receipt proves?

No. A receipt still proves the saved result was not changed after the fact, and it never proves the work was correct. Draft -21 clarifies a different claim: what a receipt id proves about the record it labels, and the honest answer when nothing binds the two.

Related