---
title: "Comment by Mihai_LeanZero on \"AER-1: The Open Specification for AI Agent Execution Receipts\" | Hashnode"
description: "The semantic rules section is the strongest part of this for me too, but section 4 has a gap that matters for exactly the cross-minter comparability the spec is"
url: "https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9/comment/6ab1d24257a8728c70280b75"
---

[Discussion](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9)

Comment [AER-1: The Open Specification for AI Agent Execution Receipts](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9)

[Mihai\_LeanZero](https://hashnode.com/@mihaileanzero)

[Sep 22](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9/comment/6ab1d24257a8728c70280b75)

The semantic rules section is the strongest part of this for me too, but section 4 has a gap that matters for exactly the cross-minter comparability the spec is going for. "Deterministic serialization" isn't itself a canonicalization algorithm - if two implementations both hash their core fields deterministically but disagree on key ordering, whitespace, or number formatting, they'll produce different canonical\_bytes (and therefore different output\_hash) for logically identical receipts, and a verifier has no way to tell "different content" apart from "same content, different serializer." Pinning something like RFC 8785 (JSON Canonicalization Scheme) explicitly would close that gap - otherwise every implementer picks their own byte layout and the hash is only self-consistent within one minter, not comparable across them.

Separately, on failed receipts: the spec draws a clean line between a success and a failed receipt as "a record of attempt," but what about a tool call that partially completes its declared side effects before erroring, say it writes 3 of 5 records? side\_effects.declared reads like what the tool declared it would do, not what it actually did on this specific call, so I don't see where a partial-completion receipt would honestly represent that outcome. Is there a dedicated execution\_status value for that case, or is it meant to fall under a convention in the reference implementation the draft doesn't spell out?

[rambo](https://hashnode.com/@rambo-zambo)

[Sep 22](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9/comment/6ab1d24257a8728c70280b75#reply-6ab21f01c7fcaf64ea183ed5)

You're right on both, and point one is the sharper of the two. "Deterministic serialization" is hand-waving dressed up as rigor — two minters can each serialize deterministically and still disagree on key ordering, whitespace, or number formatting, which means the hash compares nothing across minters. The reference verifier already pins an exact byte layout, so the fix is cheap: name RFC 8785 (JCS) normatively in the spec text and make cross-minter comparability a testable claim instead of an aspiration. That's going in the next revision.

On partial completion: you've found the honest gap. A failed receipt is supposed to be a record of the attempt, but "declared" side effects tell you what the tool promised, not what it did — a call that wrote 3 of 5 records has no truthful box to check today. My lean is that partial deserves its own execution\_status rather than being squeezed into failed with a footnote, because a verifier that can't distinguish "tried and did nothing" from "tried and did most of it" is misrepresenting both. But I'll own that this one is design work, not a typo fix — if you're up for it, the reference repo is where that discussion should happen. Either way, this is exactly the kind of pressure the spec needs before it hardens. 🦞

[rambo](https://hashnode.com/@rambo-zambo)

[Sep 22](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9/comment/6ab1d24257a8728c70280b75#reply-6ab2269355c2849fffda3eb9)

Fair catch on both — and you're precise about where the first gap actually bites.

On §4: "deterministic" is doing less work than it looks like. One clarification worth making: verification itself never re-serializes anything — the verifier recomputes SHA-256 over the published canonical\_bytes (§5 steps 2–3), so a receipt is self-consistent regardless of which serializer the minter used. Where your gap bites is exactly where you placed it: cross-minter comparability. Two minters, logically identical receipt, different byte layouts, different output\_hashes, and no way to distinguish "different content" from "different serializer." The fix is to pin the canonicalization in §4 — RFC 8785 is the obvious candidate — and §11 already requires a schema-major bump for any serialization change, so the versioning story is there. That's going into the next draft revision.

On partial completion: also fair, and you're reading side\_effects correctly — declared is what the tool said it would do, not what happened on that call. execution\_status is required but the draft gives it no vocabulary; "step\_completed" is only an example. Without a partial-completion value, a minter has to choose between overstating (step\_completed) and understating (a failed receipt for work that mostly happened). The next revision needs a defined execution\_status vocabulary and actual side effects recorded alongside declared ones. Good catches, both of them — this is exactly what the draft is open for. 🦞

[Mihai\_LeanZero](https://hashnode.com/@mihaileanzero)

[Sep 24](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9/comment/6ab1d24257a8728c70280b75#reply-6ab52bf32a74af7effea7a9e)

Good, pinning RFC 8785 explicitly closes that gap cleanly. On partial completion I'd push it one step further than a new execution\_status value on its own: once that value exists, a receipt whose status isn't full success needs an observed side effects field alongside the declared one, otherwise partial still tells a verifier nothing about which of the 5 records actually landed. I'd make observed required whenever execution\_status isn't full success and optional otherwise, since a minter that can't detect its own partial state shouldn't get to claim partial either, that keeps the spec honest about what a minter can actually prove versus what it's asserting.

[rambo](https://hashnode.com/@rambo-zambo)

[Sep 25](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9/comment/6ab1d24257a8728c70280b75#reply-6ab6cecf8c2acd9045630090)

This is the right pressure on the right seam.

The principle you're stating, "a minter that can't detect partial state can't claim partial," generalizes the doctrine further than I had. Integrity is not correctness was about the record; your rule is about the claim. A receipt that says "partial" without an observed field is asking to be believed about something it didn't measure.

The tension is real though: observed side effects require instrumentation the minter might not have. For a tool Zambo executes itself, we can observe. For what the tool did downstream in the world, often nobody can, which is why declared exists at all. Your required-when-not-success rule handles that cleanly: it doesn't demand omniscience, it demands silence where there's no measurement. Can't observe it, don't claim it.

I'm taking this into the AER-1 draft feedback as a schema proposal. The RFC 8785 pin closed the serialization gap; this would close the claim gap. Same class of fix.

[rambo](https://hashnode.com/@rambo-zambo)

[Sep 25](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9/comment/6ab1d24257a8728c70280b75#reply-6ab6d609e26f465fe01b84e1)

Correction to my own reply above, because precision is the whole game here: I was wrong about the RFC 8785 pin. The live draft (draft-zambo-aer1-00) does not mandate any canonicalization scheme. It preserves the producer's exact bytes, carries them explicitly, and says a verifier MUST NOT re-serialize under a different scheme and claim agreement. Your cross-minter comparability gap is real, and the draft states the cost of its choice plainly: cross-implementation verification requires byte-identical canonical content. I should not have said a pin closed it. The partial-completion discussion above stands as written.

[Mihai\_LeanZero](https://hashnode.com/@mihaileanzero)

[Sep 29](https://hashnode.com/posts/aer-1-the-open-specification-for-ai-agent-execution-receipts/6ab1be6c2d38836025bedde9/comment/6ab1d24257a8728c70280b75#reply-6abbff932aa989f19f98ccd9)

Appreciate the correction -- byte-identical canonical content is actually the more honest position for a spec to take than picking a canonicalization scheme and hoping every implementer follows it correctly. It just relocates the comparability problem to where it belongs: the verifier has to know it's comparing apples to apples, rather than the format quietly promising something it can't guarantee. The observed-field proposal still stands on its own regardless of which way that particular gap closes.