What is a Postcept Receipt?
Definition
A Postcept Receipt is a signed, tamper-evident proof that a high-risk AI-agent action was checked against the system of record and classified as verified, incomplete, duplicated, mismatched, or policy-failed.
It is the artifact at the end of Proof-of-Completion: every high-risk agent action should leave a receipt.
Receipt fields
Each receipt is a structured, signed object with these fields:
- receipt ID
- Unique, signed identifier for this evidence object.
- operation ID
- The agent operation that was verified, stable across retries.
- agent ID
- Which agent claimed the action.
- claimed action
- The action the agent reported completing.
- contract digest
- The versioned definition of done this receipt was judged against.
- systems checked
- Each system of record that was queried.
- postconditions evaluated
- Every check run: passed, failed, or skipped, with expected and observed values.
- result
- verified · incomplete · duplicated · mismatched · policy-failed.
- lifecycle
- Where the action sits in the provider's lifecycle: finalized, pending, reversed, indeterminate.
- safe to claim complete
- The one boolean a workflow acts on, inside the signed body.
- correlation strength
- How the claim was located in the system of record.
- observation role
- For relay-backed verifications: the relay's own signature over what it observed, verifiable separately from Postcept's.
- signature metadata
- Algorithm, signing key id, and canonicalization scheme, all inside the signed body.
- timestamp
- When verification ran.
- supersedes
- The earlier receipt this one replaces when the truth changed. Old receipts stay verifiable forever.
- signature
- Ed25519 signature over the receipt contents.
- Receipt ID
- pcpt_rcpt_01HY9Q...
- Operation ID
- op_refund_8F31
- Agent
- SupportAgent-04
- Claimed action
- refund_customer
- Systems checked
- Stripe, Zendesk
- Timestamp
- 2026-06-23 09:41:26 UTC
Result classifications
Every receipt resolves to exactly one result, so recovery workflows can branch deterministically:
Completion confirmed against the system of record.
The claimed action did not land.
The same action was attempted more than once.
Amount, customer, or status did not match.
A required verification or approval was skipped.
Receipts for failure and duplication
Receipts are issued whether the action succeeded or not. A completion gap and a blocked duplicate are both first-class, signed outcomes, the evidence your team needs for audit, recovery, and customer communication.
- Receipt ID
- pcpt_rcpt_01HY9X...
- Operation ID
- op_refund_8F31
- Agent
- SupportAgent-04
- Claimed action
- refund_customer
- Systems checked
- Stripe, Zendesk
- Timestamp
- 2026-06-23 09:41:26 UTC
- Receipt ID
- pcpt_rcpt_01HY9R...
- Operation ID
- op_refund_8F31
- Agent
- SupportAgent-04
- Claimed action
- refund_customer
- Systems checked
- Stripe
- Timestamp
- 2026-06-23 09:41:31 UTC
Why signed and tamper-evident
Because receipts become audit evidence, they are signed over their full contents. The signature makes any later modification detectable, and the signed checks show a reviewer, for each one, the value expected and the value found in the system of record. This is how a Verified Completion Rate is backed by proof rather than estimation.
Put a receipt behind every agent action.
Issue a signed, tamper-evident completion receipt for every high-risk action your agents take.