Direct answer
AER-1 Draft -23 Changelog: Anchor Outcomes, "Not Checked"
Draft -23 of AER-1, posted October 19, 2026 and expiring April 22, 2027, fixes one precise dishonesty: what a verifier says about an anchor it never evaluated. Section 6 now gives anchor outcomes a fixed vocabulary. When an anchor was not evaluated, the outcome is reported as "not checked". An evaluated anchor reports its real outcome. And a verifier must never report an evaluated outcome for an unevaluated anchor.
Updated October 20, 2026.
The Section 6 anchor-outcome vocabulary
An AER-1 receipt can be anchored externally, which gives later checkers a reference outside the producer's own record. Draft -18 and later permit anchor types including SCITT registration and RFC 3161 timestamps. Draft -23 governs how the result of looking at an anchor is reported:
- "not checked": the anchor exists but was not evaluated. This is the only honest report for an unevaluated anchor.
- verified: the anchor was evaluated and the check passed.
- verification failed: the anchor was evaluated and the check did not pass.
- "rejected: unresolvable record": the anchor was evaluated and its record could not be resolved.
- "absent": no anchor exists on the receipt.
The rule underneath the list is the change: never report an evaluated outcome for an unevaluated anchor. A verifier that skips the anchor check and prints verified has not simplified its report. It has filed a false one.
Kit, vectors, and cross-verification
Draft -23 ships with kit 1.5.6 and aer1-verify 0.2.13. The conformance corpus is 119 test vectors exercised as 122 checks, with runners in 7 languages. The file anchor-vectors.json carries 6 anchor vectors covering the outcome vocabulary. Cross-verification at this revision stands at 52 agreements and 0 disagreements between runners. Section 18 credits Skitter and a-messenger for findings folded into this revision.
What implementers must do
Report anchor outcomes per anchor, using the Section 6 words exactly. If your verifier did not evaluate an anchor, report "not checked" and make that state visible to calling code, the same discipline draft -21 applied to unbound receipt ids. If no anchor exists, report "absent", which is a different fact from "not checked": one says there was nothing to evaluate, the other says there was something and it was not evaluated. Then run the 6 anchor vectors and the full kit, 119 vectors and 122 checks, and confirm your outcomes match on every one.
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
The vocabulary governs reporting, not anchoring itself: draft -23 does not require any receipt to carry an anchor, and an absent anchor is a complete, honest state. It also does not upgrade what a receipt proves. An anchor outcome says what happened when the anchor was checked; the receipt itself still proves only that the saved result was not changed after the fact, never that the work was correct.
Frequently asked questions
What changed in AER-1 draft -23?
Draft -23, posted October 19, 2026 and expiring April 22, 2027, adds the Section 6 anchor-outcome vocabulary. When an anchor was not evaluated, the outcome is reported as not checked. An evaluated anchor reports its real outcome: verified, verification failed, or rejected: unresolvable record. Absent is reported when no anchor exists. Kit 1.5.6 ships 119 vectors and 122 checks, and Section 18 credits Skitter and a-messenger.
What does "not checked" mean for an AER-1 anchor?
It means the receipt carries an anchor and the verifier did not evaluate it. That is the only honest report for an unevaluated anchor. It is different from absent, which means no anchor exists, and different from verified, which means the anchor was evaluated and passed. A verifier must never report an evaluated outcome for an unevaluated anchor.
What are the Section 6 anchor outcomes in draft -23?
The vocabulary has five reports. Not checked, when an anchor was not evaluated. Verified, when an evaluated anchor passed. Verification failed, when an evaluated anchor did not pass. Rejected: unresolvable record, when an evaluated anchor's record could not be resolved. And absent, when the receipt carries no anchor at all.
What must implementers do about draft -23?
Report anchor outcomes per anchor, using the Section 6 words exactly, and make the state visible to calling code. Report not checked for any anchor you did not evaluate, and absent only when no anchor exists. Then run the anchor vectors, 6 vectors in anchor-vectors.json, and the full kit: 119 vectors and 122 checks at kit 1.5.6 with aer1-verify 0.2.13.
Does an anchor make an AER-1 receipt prove more?
No. An anchor gives later checkers a reference outside the producer's own record, and the Section 6 outcome reports what happened when that anchor was checked. The receipt itself still proves only that the saved result was not changed after the fact. It never proves the work was correct, with or without an anchor.