Product
Proof receipts make implementation memory auditable.
Generic memory can recall context. Moresq receipts show what was retrieved, why it was trusted, what it cost, who should be notified if it fails, and how the system should learn from the outcome.
Receipt anatomy
A retrieval should leave evidence.
The receipt is the stable contract between the agent, the developer, the snippet contributor and the review system.
Identity
artifact id, version, content hash, source path and retrieval timestamp
Trust
scan model, trust tier, usage count, incident count and review status
Rights
license, provenance attestation, revocation state and report path
Economics
credits charged, estimated tokens saved, estimated time saved and split accounting
Learning
apply success, failure, correction or incident signals tied back to the receipt
Lifecycle
Search
Agent receives metadata and previews only.
Retrieve
Full implementation card is served with a receipt.
Apply
Agent adapts the card and reports success or failure.
Learn
Corrections and incidents become eval examples or review tasks.
Revoke
Bad cards can be pulled and prior consumers can be identified.
Example payload
{
"receipt_id": "cr_27f9",
"artifact_id": "stripe-webhook",
"version": "sha256:9ad0c8f1a542e3b1",
"trust_tier": "battle_tested",
"license": "internal approved",
"credits_charged": 5,
"estimated_tokens_saved": 612,
"report_tool": "corpus.report_issue",
"learn_tool": "corpus.learn"
}Why it matters
A receipt is not a trust badge.
A receipt does not make an implementation correct, secure or appropriate for every repository. It records the evidence needed to make that judgement: where the artifact came from, when it was reviewed, what license applies, which tests exist and what happened when another agent used it.
This distinction matters when a reusable pattern crosses project boundaries. The receiving agent can adapt names and interfaces, while the developer can still inspect the original assumptions and reject the retrieval when the match is weak.