---
name: proof-receipts
description: Integrate durable pass state for a named expensive project proof when the user explicitly requests it or repeated measured proof cost justifies it. Do not use for ordinary verification decisions, inexpensive tests, or speculative caching.
---

# Proof receipts

Use this pattern only when repeated proof cost is known and material. A receipt is project infrastructure, not a reason to avoid ordinary focused verification or add speculative caching.

Recover one answer: has this exact proof scope already passed?

## Choose the fit

Inspect the project’s existing commands and proof state. Keep a specialized mechanism when it already answers safely or carries guarantees beyond key lookup. Otherwise choose the smallest implementation native to the project.

## Receipt contract

A receipt maps one deterministic, project-owned key to one passing result.

- The key covers the proof contract, relevant dependencies, and any platform, toolchain, profile, or artifact identity that changes what passed.
- An exact match recovers the pass. Anything else makes no claim.
- Check before expensive building, setup, or resource acquisition.
- The project’s existing command performs the proof.
- Record only after success and while the same key remains current.
- Without a trustworthy key, do not add a receipt.

A whole-tree key is conservative. A dependency closure avoids invalidating unrelated proofs.

Script the integration behind the project’s existing entry point. Confirm that covered changes invalidate the key, unrelated changes do not, and failure or a changed key leaves no receipt.

Keep one small current record per proof. Do not retain receipt history, artifact copies, workspaces, or log bundles.