Receipt
The signed, verifiable record of what happened and what it cost — decision, tool manifests, cost, consent, and settlement joined into one object.
A Receipt is the signed, verifiable record of what happened and what it cost
— Receipt (WorkReceipt) in the API. It joins the
route's explanation, a signed manifest for every tool an agent invoked, the cost
in exact units, the consent trail, and the settlement reference into one object:
the artifact you hand an auditor, a customer, or a counterparty when they ask
what exactly happened, and what did it cost.
The evidence exists today as separate records — decision explanations, content-hashed tool-exposure manifests, per-request cost accounting, consent certificates. The unified, signed receipt is the object that joins them and makes "provable" literal.
shipping — the joined WorkReceipt aggregate, its Ed25519 signer, the verify
surface, and JWKS key publication are live; issuance is enabled per deployment
behind a config gate.
What "signed" means
A receipt is immutable and Ed25519-signed. Signing binds a versioned canonical serialization of the payload — including the algorithm and signing-key id, under a domain-separation constant — so a verifier can recompute the hash, check the signature against a key published via JWKS, and confirm the key was valid when the receipt was issued — offline, without calling Ductor. Lifecycle state is never inside the signed bytes: it is derived, so a receipt settling later can never disturb its signature. A redacted shareable receipt is a distinct re-signed object issued under a revocable, expiring share grant — never a blanked copy of the original, and the full receipt is never public.
WorkReceiptAssembled at terminal outcome from the evidence records.
WorkReceiptCanonical bytes signed and stored.
WorkReceiptFinalized once settlement commits.
WorkReceiptA claw-back appends a compensating receipt — the original is never mutated, and amendments carry stable identities so retries converge instead of duplicating.