Receipt Verification

VaultCrux receipts are signed evidence records that allow independent replay and audit of retrieval/proof outcomes.

What a receipt proves

Which tenant-scoped request produced the result.
Which evidence/chunk lineage supported the outcome.
Which service/version context produced the response.
That payload integrity has not changed since signing.

Deterministic answer replay

Replay is not regeneration. For replayable answers, Crux stores the produced answer plus the evidence capsule, source hashes, semantic profile metadata, and projection module references needed to render the historical answer again without calling the original agent or LLM.

Replay has two separate views:

Historical replay renders what was produced at the time.
Current validity checks whether chunks, Living Objects, or projection modules have drifted since the answer was produced.

Verification workflow

Capture the receipt ID from your API or tool response.
Fetch the receipt/proofpack payload from the published endpoint for that flow.
Validate signature/integrity fields against the payload body.
Compare referenced chunks/artifacts to your expected corpus context.
Store the verification result in your audit log.

API surfaces

Receipt-bearing responses are exposed by retrieval/proof workflows.
Proofpack retrieval route: GET /v1/proof/receipts/:receiptId/proofpack
Canonical contract reference: OpenAPI JSON

Recommended controls

Treat receipt validation as a required step for high-risk or externally shared outputs.
Archive original receipt payloads with immutable timestamps.
Alert on signature mismatch, missing referenced artifacts, or lineage drift.

Common failure states

Receipt missing: response path did not produce a receipt-eligible action.
Signature mismatch: payload changed after issuance or signature validation key mismatch.
Stale lineage: receipt is valid but source evidence has since drifted.
Module drift: historical replay is available, but current projection code or configuration has changed.