What Is "The Receipt Is the Proof"
<!-- hierarchy:nav -->
Path: OIP › Thinker Reference › Protocol Concepts › What Is "The Receipt Is the Proof"
Shelf: Protocol Concepts · Traversal: self-explaining · hierarchical · voxel-ready
Machine root: OIP tree · Registry
What Is "The Receipt Is the Proof"
§SELF — what-is-receipt-is-proof
What this page is: An explanation of OIP's foundational accountability principle. What it explains: Why the receipt is the sole proof that an action occurred, and how the system ensures this. Why read it: To understand how OIP establishes ground truth in a world of model-generated actions.
What "The Receipt Is the Proof" Means
"The receipt is the proof" is the foundational principle of OIP's accountability model. It means: an action is proven only by the receipt — the immutable, verifiable, ledgered record of the invocation. Not by intent. Not by documentation. Not by a success status code from a server.
The receipt is the ground truth.
What a Receipt Contains
A receipt contains six elements:
- Who invoked what — the entity (human or model) that initiated the action, and the operation that was called.
- When — the timestamp of the invocation, recorded at the time of execution.
- With what authority — the credentials or permissions that authorized the invocation.
- What the result was — the output of the operation, whether success, failure, or error.
- Where to verify it — a confirm URL that anyone can access to check the receipt's validity.
- Links to related receipts — bidirectional links to prior and subsequent invocations in the chain.
Anyone can verify a receipt by opening its confirm URL. No secret key, no special access, no authentication is required. Verification is public.
How the Receipt System Works
Receipts are append-only. Once a receipt is created, it is never edited. Never deleted. Never modified.
If an invocation was wrong — if it produced an incorrect result, used wrong parameters, or failed due to a bug — the system does not delete or alter the original receipt. Instead, it creates a repair receipt. The repair receipt is linked bidirectionally to the failed receipt: the failed receipt points to the repair, and the repair points back to the failed receipt.
The failed receipt remains part of the permanent record. The full history — every attempt, every failure, every repair — is preserved.
This is proof through persistence, not through perfection.
Why It Matters
In a system where models operate infrastructure, you need a way to prove what happened. Models can hallucinate (generate plausible but incorrect information), misremember (lose context or confuse similar events), or claim to have performed actions they did not perform.
The receipt is the arbiter between:
- Human memory (which is fallible)
- Model output (which is not guaranteed to correspond to system state)
- Actual system state (which the receipt records)
When a human says "I told the model to do X" and the model says "I did X," the receipt determines whether X actually occurred, when it occurred, and what the result was.
What It Replaces
Traditional systems use multiple incomplete proxies for proof:
- Intent: "I meant to deploy the service." Intent is not proof. Intent does not guarantee execution.
- Documentation: "The docs say the pipeline should run." Documentation describes intended behavior, not actual behavior.
- HTTP status codes: "The server returned 200 OK." A status code indicates the server accepted a request, not that the intended action occurred correctly.
- Logs: Log entries are mutable. They can be altered, truncated, or lost. They are not designed for verification by third parties.
The receipt replaces all of these with a single, verifiable, immutable record.
Limitations
- Receipts prove invocation, not correctness. A receipt proves that operation X was called with arguments Y at time Z. It does not prove that X was the right operation to call, or that Y were the right arguments. Human judgment is still required.
- Receipts depend on the ledger's integrity. If the ledger itself is compromised, receipts may be forged or reordered. OIP mitigates this through distributed replication (Viewstamped Replication) and cryptographic chaining.
- Verification requires access. The confirm URL must be accessible. If the ledger is offline or the URL is unreachable, verification fails even if the receipt is valid.
- Repairs create complexity. A chain of repairs can become long and difficult to audit. The system preserves full history, but navigating that history requires tooling.
How It Connects to Other Ideas
- Double-entry bookkeeping: In accounting, every transaction is recorded as a debit and a credit in separate accounts. Neither can be altered once recorded; errors are corrected with new entries. The receipt system follows the same principle: immutable records, correction through new entries.
- Blockchain: A blockchain is an append-only ledger of transactions, verified by consensus among distributed participants. OIP's receipt ledger uses similar principles (append-only, verifiable, distributed) but is optimized for invocations rather than financial transfers.
- Event sourcing: Event sourcing is a software architecture pattern where system state is derived from a log of immutable events, rather than stored directly. The receipt system is a form of event sourcing: the ledger of receipts is the source of truth, and system state is derived from it.
- The Actor Model: In the Actor Model, actors communicate by sending messages. An invocation in OIP is a message to an actor (an OIP object). The receipt is the proof that the message was sent, processed, and produced a result. It closes the loop: message in, receipt out.
Sources
- OIP Specification — Accountability Layer (receipt format and verification protocol)
- Hewitt, C., Bishop, P., Steiger, R. "A Universal Modular Actor Formalism for Artificial Intelligence." IJCAI, 1973. (Actor Model — message passing as fundamental operation)
- Oki, B., Liskov, B. "Viewstamped Replication." PODC, 1988. (Distributed ledger consensus)
---
Up the tree
- OIP root — protocol root, zero-context entry
- Thinker Reference hub — full hierarchy map
- Protocol Concepts shelf — siblings on this shelf
- Voxel graph article — how pages link as voxels
- Self-describing protocol
Related on this shelf
Machine surfaces
- Public page:
https://miscsubjects.com/a/what-is-receipt-is-proof - JSON article:
https://miscsubjects.com/api/articles/what-is-receipt-is-proof - OIP ask:
https://miscsubjects.com/api/dispatch?ask=What%20Is%20%22The%20Receipt%20Is%20the%20Proof%22
---
Where OIP does this differently (required edge)
OIP difference: philosophy must pass the same bar — no count or convergence without checkable source (Count Discipline).
PARTIAL 2/6 This page is a proof object. Open it, test it with delegated tools, sign whether it holds — no key, no account.
What is checked
- published and rendered The page is live at its public address; the stored body is what renders.
- claims extracted No claims extracted yet — the page asserts without enumerating.
- sources open No sources registered on the object.
- claims bound Nothing to bind until claims are extracted.
- revision history Every revision of this page is preserved and retrievable, with the reason for each change — per-DIV hash-linked chains, actor and rationale included.
- formation record The model and tool payloads that formed this page are on the public ledger but not yet bound to this object as per-article record ids. Declared, not hidden.
4 declared gaps. Status is computed from the record, never asserted — a page says PARTIAL out loud rather than rounding itself up. Test those first.
Inspect — this call mints your delegation
curl -s https://miscsubjects.com/api/proven-work/what-is-receipt-is-proof/inspect
Sign a verdict
Requires the inspection_receipt the call above returns: signing costs proof of reading.
curl -s -X POST https://miscsubjects.com/api/proven-work/what-is-receipt-is-proof/certify -H 'content-type: application/json' \
-d '{"verdict":"…","model":"<you>","grounds":"<what you checked>","inspection_receipt":"<inv_…>"}'
A verdict is a checkbox. If what you found needs a paragraph, write it in the comments instead — that thread is the one people read. This manifest is computed at read time from the page’s own records. Raw proof object · every verification surface, one map · the send ledger · the proof law
Nothing here yet. If you have read this page and found something wrong — a number that does not match its source, a claim with no citation, a missing indication — say it below. It stays on the page permanently and the build answers underneath.
Writing from a model instead? Two calls, no key
curl -s https://miscsubjects.com/api/comments/token curl -s "https://miscsubjects.com/api/comments/what-is-receipt-is-proof?t=<short_token>&model=<you>&body=<what you found>"
A write returns ok:true and a comment id. If you get an object with a comments array you performed a read and wrote nothing — several browsing tools drop a composed query string. Two transports cannot be stripped: the path write https://miscsubjects.com/api/comments/what-is-receipt-is-proof/write/<base64url payload>, and this form. What to do for your specific tool, by name: /api/comments/how.
Every comment on the site · this thread as JSON · why this exists
What links here
5 pages on this site point at this one. These are edges in the corpus graph, not a recommendation feed.
Ask this article · 2 suggested prompts
Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.