The evidence
Corpus vector: hash-mismatch.json
The AER-1 conformance corpus (126 vectors, 129 checks, kit v1.5.7, published at zambo.dev/aer1/corpus.json) files this record in its invalid set. Receipt id b6c63ac5-f324-4fa7-ad58-c4bf83faa86a, tool live_price, carries output_hash sha256:0000000000000000000000000000000000000000000000000000000000000000. The vector carries its own rejection reason, verbatim: "output_hash does not match sha256(canonical_bytes)". Read the vector live: hash-mismatch.json (file SHA-256 6037f4dd7abe55c8fcf88224e7fe02ef0ea7eccbde462d4f16263dc8557f9228 in the corpus index).
Corpus vector: input-hash-mismatch.json
The same failure on the input side. Receipt id 22c64420-500f-498a-be52-d7011647bb2b carries an input_hash of sha256:234d4853baf5c9c5e5f526489050b770c32ee7abf3b9ec5a0c962907ce322f7a, and the vector's rejection reason reads, verbatim: "input_hash does not match sha256(canonical JSON of the recorded inputs)". Read it live: input-hash-mismatch.json (file SHA-256 5c745d87db58d21ab577759eb83976988b59aa17830fb10eec2709e5603281a6).
The same pattern in the commitment and anchor sets
The commitment vector file includes commit-digest-mismatch with expected verdict invalid (commitment-vectors.json). In the anchored set, anchored-bad-leaf-hash.json carries an anchor leaf_hash of all zeros against an output_hash of sha256:c2258bdf9c34813a70166bc0e2d79b167f22f51a0adb67e218b5c868b911dca7: the anchor leaf does not match the receipt it claims to anchor.
What the verifier reports
Under the AER-1 Section 6 outcome vocabulary, a digest that was recomputed and did not match is verification failed. It is not "not checked" (the check ran) and it is not "absent" (the digest was present). Reporting the exact outcome matters: a mismatch means the record in hand is not the record that was saved, whatever the reason.
How to fix it
- Do not edit a saved result and keep its receipt. Any change to the recorded bytes changes the recomputed hash. If you need to annotate a result, annotate outside the record.
- Re-fetch the record from its public run link instead of trusting a forwarded copy. A copy that was re-serialized, truncated, or pasted through a tool that alters bytes will fail even when the original passes.
- If the re-fetched record still mismatches, treat the copy as not the saved record and ask the issuer to resend the original, or rerun the call so a fresh receipt is issued for the new result.
- Check it yourself before you argue about it: paste the receipt link into the public verifier at zambo.dev/verify and read the commitment check line by line.
Put your own calls on a checkable record
Start at zambo.dev/add
Add Zambo to your AI at https://zambo.dev/add/. The free tier is 20 free calls per day, then they upgrade. A Day Pass is $0.99 for 24 hours. Every call returns a verifiable receipt, including a call that is rejected, so a failure like the ones on this page leaves a record you can open, check, and learn from instead of a claim you have to trust.
A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was right.
Questions
What does a wrong digest mean on an AER-1 receipt?
It means the SHA-256 hash recomputed over the receipt's canonical bytes does not equal the output_hash the receipt carries. The check ran and did not pass, so the verifier outcome is verification failed. The corpus vector hash-mismatch.json shows the pattern with an all-zero output_hash and the rejection reason: output_hash does not match sha256(canonical_bytes).
Does a wrong digest prove someone cheated?
No. A mismatch proves only that the bytes in hand are not the bytes the commitment was computed over. Re-serialization, truncation, a copy error, or an actual edit all produce the same outcome. The fix is to re-fetch the record from its public run link and check the original.
Can I fix a wrong digest by updating the hash on the receipt?
No. Replacing the hash makes a new claim, not a verified record. The commitment only means something because it was computed when the call ran. If the saved result changed, rerun the call and keep the fresh receipt it returns.