The evidence
Corpus vector: missing-output-hash.json
Receipt id b6c63ac5-f324-4fa7-ad58-c4bf83faa86a, tool live_price, carries a verification_status claim of "verified" but no output_hash member at all. The vector's rejection reason reads, verbatim: "missing required member: output_hash". A status claim with no commitment under it is exactly what this class catches. Read it live: missing-output-hash.json (file SHA-256 cea9fc18f725b7a55f627f9347cd6da1b634892588bb163af7fbb49712c200d3 in the corpus index).
Corpus vector: missing-inputs.json
Filed in the corpus invalid-profile set. Receipt id 55406ade-3c05-4b35-8c82-fe146d9c16d0: its canonical bytes carry the tool, the outputs, and a millisecond count, and no inputs member. The record says what came back and cannot show what was asked. Read it live: missing-inputs.json (file SHA-256 8041ed4574a7b26a44fa553d2dc93aebbe091a7257e16c10f828c8fbe9161b94).
Fail closed, in the workflow set
The cross-version workflow vector xversion-receipt-id-v0-evaluated-as-seq-output-v1 is rejected with the reason, verbatim: "missing output_hash: seq-output-v1 leaf cannot be formed (fail closed)". The steps carry no output_hash, so the leaf the declared rule needs cannot be built, and evaluation stops instead of guessing. Read it in workflow-merkle-seq-output-v1.json (file SHA-256 30b63977d7ccc4177e2c2524520dcbbb0a352c572561aa3d3c4fe4d60cf55f40).
What the verifier reports
In the AER-1 Section 6 vocabulary this is rejected: unresolvable record. The record as issued cannot be resolved into the bytes its commitment is supposed to cover, so there is no evaluated pass or fail to report. That is a different fact from "not checked", which means a check existed and was not run.
How to fix it
- Agents: supply every required argument. A call made with a required argument missing is rejected, and under AER-1's every-call rule the rejection itself returns a receipt, so the failure is on the record instead of vanishing. Read the rejection, add the missing argument, and retry.
- Producers: emit the complete record. A receipt without its output_hash, inputs reference, or other required members is not a shorter receipt, it is an unresolvable one.
- Verifiers: fail closed. Never synthesize a missing member, never treat a claimed status as a check. Report the record as rejected: unresolvable record, and name the missing member, the way the corpus vectors do.
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 happens when an AER-1 receipt is missing a required field?
The verifier cannot reconstruct the canonical bytes or form the value the missing field feeds, so the record is rejected: unresolvable record. The corpus vector missing-output-hash.json states the reason plainly: missing required member: output_hash.
Is a missing field the same as a failed check?
No. A failed check was evaluated and did not pass. A missing field means there was nothing complete to evaluate. AER-1 keeps the two outcomes separate so a reader can tell a broken record from an unchecked one.
My tool call was rejected for a missing argument. Is there a record of it?
Yes. Under the every-call rule in AER-1 Section 3, receipts issue for rejected calls too. The rejection receipt is the record of what was attempted and why it did not run, and it is the thing to read before retrying with the argument supplied.