Summary

  • Revision 04 of the individual AER-1 Internet-Draft requires workflow leaves made from each step's receipt_id; the current public workflow page makes leaves from seq:receipt_hash instead.
  • All five public step receipts verified and their output hashes matched the workflow manifest. The page's algorithm reproduced its published root exactly, while the draft's algorithm produced a different root.
  • The repository's Python, Rust and TypeScript helpers follow the draft, but the advertised 43-vector corpus is marked revision -03 and contains no workflow-root vector. A perfect score therefore says nothing about this new boundary.

Two correct calculations cannot authorize one unnamed object

The first root is a4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4. It appears on a public Zambo workflow page for a five-step “get BTC price” run. The page tells a browser to fetch every step receipt, require each one to verify, compare its output hash with the workflow manifest, and build a binary Merkle tree. Fresh checks on all five endpoints returned HTTP 200. Every receipt reported verified: true. Every output hash matched.

The browser then did exactly what the page documented. For each step it hashed the UTF-8 bytes of the sequence number, a colon and the lowercase step hash: seq:receipt_hash. Pairing raw 32-byte children and duplicating the final child at an odd level reproduced the published root exactly.

The second root is 7c4817ca249edfeae259b98abf63ed38a31d9dbeebf5ee23139410a7a7f63b37. It comes from the same five steps, in the same order, with the same SHA-256 parent rule and the same odd-node duplication. Only the leaves change. Instead of sequence plus output hash, they are SHA-256 over the UTF-8 bytes of each step's receipt identifier.

That second construction is not an alternative invented for this review. It is the construction required by revision 04 of AER-1: A Portable Execution Receipt for AI Agent Tool Calls, posted on 29 September 2026. The document is an individual Informational Internet-Draft, not an RFC or an adopted IETF Working Group item. Its status limits the standards claim. It does not make the observed divergence less concrete.

The important fact is unusually clean: neither result depends on a malformed receipt, missing step, hash collision or speculative interpretation. Both roots can be reproduced. They identify different trees.

The disagreement begins before the first branch

A Merkle root is often discussed as though “SHA-256” were the whole contract. It is not. A verifier must also know what becomes a leaf, how that input is encoded, whether child digests or their hexadecimal text are concatenated, what happens to an odd child and how the final value is represented.

Revision 04 says the root binds the ordered step receipt identifiers. Its procedure hashes each receipt_id string as UTF-8, pairs raw digests, duplicates the last digest when a level is odd, and encodes the final digest in lowercase hexadecimal. The section first calls this construction recommended, then makes the rule normative: implementations must use it. It explicitly says the permission for alternative constructions was removed because different roots for the same workflow break cross-implementation verification.

The public workflow page agrees on the binary tree mechanics but selects a different object. Its leaf includes the step's position and output commitment. That design has an intelligible property: it binds order and output hashes directly into the leaf. The draft's design also has an intelligible property: it defines the workflow over stable receipt identities and relies on independent resolution of each receipt.

This Article does not choose the better design. It reports that they are different designs. A root cannot tell a later reader which one created it. Sixty-four hexadecimal characters carry no self-describing leaf semantics.

That is why a bare root is a dangerous decision token. Once copied into an approval record, audit package or settlement instruction, it can look universal while belonging to only one compatibility set.

The running system and the written rule have already forked

The public repository helps locate the split. At commit f3aacbb5cf7d00977fd107afc34fc24b08c4f569, fixed on 29 September, the Python helper accepts receipt_ids and hashes each encoded identifier. The Rust helper hashes every id.as_bytes(). The TypeScript helper hashes each identifier as UTF-8. All three apply the same binary parent and odd-node rules described in revision 04.

The live workflow page does not call those helpers in the browser. Its JavaScript independently fetches the step verification records and constructs seq:hash leaves. The written rule and three repository helpers occupy one compatibility set. The observed page occupies another.

Running-code discipline requires both facts. It would be a mistake to say the draft automatically overrides deployment because the document is newer. Publication does not migrate a public receipt. It would also be a mistake to say the deployed page defines the portable contract merely because it runs. A deployed implementation can be internally coherent and still fail to interoperate with another implementation following the current text.

Lu Heng's minimum-specification principle makes the missing boundary visible. A thin common layer does not mean an underspecified layer. The leaf bytes are part of the smallest deterministic rule needed for independent validation. If that choice is left to a page, library or institutional explanation after the fact, the system has hidden authority inside what appeared to be a neutral hash.

Why 43 out of 43 did not see the split

The repository reports 43/43 for runners in Rust, Go, TypeScript, Python, Java, C# and Swift. That is useful evidence, but its authority is bounded by the corpus.

The implementation README describes the tested rules: required receipt members, UUID and timestamp validity, strict base64 and UTF-8, output commitments, provenance classes, the reference-producer input profile, optional anchors and emitter round trips. Workflow receipts are not on that list.

The vector index is more decisive. It identifies specification revision -03, not -04. Its 43 fixtures cover ordinary valid and invalid receipts, producer-profile cases and anchored records. No vector identifier, group or fixture tests a workflow, Merkle root, step sequence, step hash, odd final node or either leaf encoding.

Every runner can therefore score perfectly while the newly added workflow feature remains untested. The badge is not false. The inference is. “43/43” means forty-three named verdicts matched. It does not mean every behaviour described by a later revision agrees across the website, browser code and seven languages.

A useful workflow vector would expose more than an expected final root. It would freeze the five receipt identifiers, expected leaf inputs, leaf digests, every intermediate level, odd-node duplication and final lowercase value. It would then run through the deployed page, API path and each language helper. A failure would identify the exact boundary rather than merely report that two opaque roots differ.

“Verified” names at least six separate facts

The five public steps passed their own integrity checks. That matters. It means the workflow mismatch should not be narrated as broken evidence. It should be narrated as evidence aggregated under different rules.

At least six propositions must remain separate:

  1. Step integrity: the canonical bytes of each receipt match its output commitment.
  2. Manifest binding: the output hash fetched for each step matches the hash displayed by the workflow page.
  3. Leaf semantics: the verifier selected the field or compound value required by a named construction.
  4. Root compatibility: another verifier using that same construction obtains the same root.
  5. Witnessing: an external service recorded the chosen commitment at a time and under an identified key.
  6. External effect: the underlying tool action produced the business or real-world consequence a consumer cares about.

The current page demonstrates the first two and its own version of the third and fourth. Its workflow anchor can add a witness to the chosen root; the page labels the anchor status partial. An anchor cannot repair semantic disagreement. It can prove that one root was published, not that the root was built under revision 04.

Nor can either tree upgrade provenance. A step logged by an external agent remains a report. A gateway observation remains a gateway observation. A hash over the sequence cannot turn invocation into delivery, a price query into a trade, or an output commitment into authorization.

The word “verified” is therefore incomplete without an object. Verified bytes? Verified step identity? Verified workflow construction? Verified anchor? Verified external effect? A reliable interface answers that question before it shows green.

A root needs a construction passport

For a workflow root to travel between an agent platform, auditor and decision system, it needs a compact acceptance profile. At minimum that profile should carry the receipt and workflow schema versions; a leaf-construction identifier; exact byte encoding; hash and parent rules; odd-node treatment; output encoding; ordered step identifiers and commitments; per-step provenance; the definition of the workflow's final output bytes; anchor scope; and the vector version that tested the construction.

The acceptance decision should record its own policy version and principal. This is not bureaucratic decoration. It answers the question that the two roots force: who accepted which object under which rule?

A migration from seq:receipt_hash to receipt_id should not silently recompute old roots. Historical receipts promised stable public URLs. The defensible path is to preserve the original commitment, publish a versioned successor or explicit superseding record, and—during transition—calculate both roots with clear labels. Consumers can then choose a compatibility set without being told that history always meant the new rule.

This is voluntary adoption in its operational sense. The new text becomes reality when implementations, fixtures and deployed surfaces converge. Until then, an honest verifier reports the split.

Sources and limits

The observations were frozen on 30 September 2026 Asia/Shanghai. They establish a reproducible difference among revision 04, a fixed public repository commit and the then-current public workflow page. They do not establish malicious conduct, a SHA-256 weakness, compromise, external-action failure, broad adoption or IETF endorsement. Only the Python, Rust and TypeScript workflow helpers were inspected. The Internet-Draft and live service may change.