Check result receipts and provenance
How to read a result receipt, verify its signature, and tell what it proves from what it does not, such as delivery or payment.
Read the receipt before interpreting it
Use the receipt identifier associated with the action you are reviewing. The REST read is GET /v1/receipts/{id} with current jobs:read access, and the TypeScript client exposes getReceipt(id). Follow this order: read the receipt, verify its declared signature, interpret the recorded outcome, then reconcile usage.
Your agent can fetch and compare receipt evidence as part of its workflow, while you keep the final judgment about the result. A receipt identifies a signed statement and its covered action; it does not replace result review, business approval or payment confirmation.
Its public receipt projection contains receipt_id, receipt_digest, signature_key_id and signature. That projection is not the complete signed receipt body, the result content or an invoice.
A receipt traces the defined action, execution identity and evidence or result digests covered by its signed statement. It does not explain every token's reasoning, prove semantic correctness or promise a completed pull request. For coding work, your existing agent reviews the finding, makes local edits, runs native builds and tests, and decides whether the work is accepted.
Different receipt families cover different actions. Confirm the receipt's schema and coverage before interpreting it. Do not treat a submission receipt, execution receipt, delivery record and payment record as interchangeable.
Verify the declared signature
Use verification tooling approved for the exact receipt version. It needs the signed material and an independently trusted verification context. Do not obtain a new trust root solely from the untrusted receipt you are checking.
Check the allowed algorithm, signing-key role, validity and revocation information. Verify the specified signing domain and canonical bytes. Reformatting JSON or substituting a different receipt schema can change the signed meaning. A checksum or digest helps identify bytes; it is not a correctness judgment.
Match the receipt to the expected result and evidence identities. A valid signature on a different job is not a valid receipt for your job. Stop on a schema, signature, key or correlation failure; preserve the safe failure code.
Interpret the recorded outcome
A signature authenticates a statement under the selected trust policy. It does not prove that the statement's measurements are truthful, that the model's answer or downstream decision is correct, or that payment settled. A checksum is not correctness, and a valid signature on the wrong result is not evidence for this result.
A verifier can compare evidence supplied by its caller without independently reproducing the original execution. Record which checks the tool performs and which facts came from other authorities. Missing proof is not a successful verification. Let the agent use that distinction when it decides whether to accept, repair or escalate the returned work.
Follow the provenance chain
Read the workflow's provenance record with the original input snapshot. Confirm the source version, requested output schema and applicable model or runtime version. Match referenced artifacts to the accepted result, not to a similar filename.
Compare those identities with the prepared brief's frozen instructions, rubric and acceptance rule. The provenance chain can show which input and schema the result used; the agent still checks coverage, uncertainty and semantic correctness before synthesis.
For a synthetic document extraction, provenance might identify document DOC-01 version A and schema revision 2. A row extracted from version B is the wrong subject, even if its total looks plausible. Preserve that mismatch instead of correcting the record by hand.
Keep provenance references customer-safe. Do not copy private input, bearer URLs, credentials or internal infrastructure details into an audit export.
Reconcile usage after the recorded outcome
Compare the approved quote and maximum with the accepted usage record under the applicable commercial policy. Requested candidates, accepted work and infrastructure retries are different populations, and physical attempts are not automatically customer billing units. The quote defines the accepted billing unit; an output count alone cannot calculate a charge. Use Billing and reporting for the authoritative commercial records.
A receipt containing an invoice reference does not establish that payment settled. A delivery digest does not establish that someone opened or approved the content. Seek the corresponding authoritative record for each conclusion.
Recover incomplete receipt material
If the public projection is all you have, retain it and obtain the version-matched signed material through the supported account channel. Do not invent missing fields or mark verification complete just because the JSON parsed.
If the key context is unavailable, report verification as incomplete. A bounded re-read of the existing receipt is different from rerunning inference. Escalate using safe receipt and job references plus the failed check.
Continue with result retention and deletion to decide which evidence and copies your team needs to keep.