Our own audit caught our draft describing yesterday's rule: AER-1 revision 25

Description and use

Revision 25 aligns the IETF draft and the published implementation by defining both seq-output-v1 and receipt-id-v0 root constructions side by side, pointing verifying clients at /api/v2/, deprecating the v1 endpoint, and extending the receipt rule to cover all calls including rejected ones. The conformance corpus expanded to 124 vectors and 127 checks against kit v1.5.7, and both reference runners pass against the exact corpus files. Every pre-existing receipt continues to verify exactly as before.

Problem

A published implementation change to how workflow closes compute Merkle roots introduced a new rule construction (seq-output-v1) and a new merkle_version field, but the IETF draft revision 24 still described only the legacy receipt-id-v0 rule. Anyone building a verifier from the draft alone would fail every new workflow root.

Outcome

Revision 25 aligns the IETF draft and the published implementation by defining both seq-output-v1 and receipt-id-v0 root constructions side by side, pointing verifying clients at /api/v2/, deprecating the v1 endpoint, and extending the receipt rule to cover all calls including rejected ones. The conformance corpus expanded to 124 vectors and 127 checks against kit v1.5.7, and both reference runners pass against the exact corpus files. Every pre-existing receipt continues to verify exactly as before.

Workflow

• Ship a batch of fixes for defects filed by paying agents; one change alters how new workflow closes compute Merkle roots by adding seq-output-v1 and a merkle_version field.
• Run a deep audit on the published changes.
• Discover that the IETF draft revision 24 still describes only the receipt-id-v0 rule, so a verifier built from the draft alone fails every new workflow root.
• Publish revision 25 to align the paper and product: define both root constructions side by side, point verifying clients at /api/v2/ endpoint, deprecate the v1 endpoint, and state the receipt rule at full scope including rejected calls.
• Publish the conformance corpus: 124 vectors and 127 checks against kit v1.5.7, including seq-output-v1 workflow cases, served with evaluated-set digest at https://zambo.dev/aer1/corpus.json.
• Verify that both reference runners pass against those exact files and that every receipt issued before today verifies exactly as it did yesterday.

Evidence

This morning we shipped a batch of fixes for defects our paying agents filed from real use. One of them changed how new workflow closes compute their Merkle roots: each leaf now binds the step's sequence number and its output hash, a construction we call seq-output-v1, and every close names its rule in a merkle_version field.

Older closes keep the original rule, receipt-id-v0, where each leaf is the hash of the receipt ID, and their stored roots still recompute exactly under it.

Tonight our own deep audit caught what that publish left behind. The IETF draft, revision 24, still described the receipt-id leaf as the only rule allowed. Anyone who built a verifier from the draft alone, which is exactly what a draft is for, would fail every new workflow root.

The lesson we keep relearning in public: a standard is only worth what a stranger can reproduce from it. When the implementation learns something the paper does not know yet, the paper is the bug.

Both root constructions are defined side by side. seq-output-v1 is the current rule; receipt-id-v0 is kept as the legacy rule, so a close made under either verifies under the rule it declares in merkle_version.

Verifying clients are pointed at the /api/v2/ verification endpoint, whose passing outcome reads 'verified'. The v1 endpoint answers 'commitment_matches'