- Pass Registry table added, back-filled, and reversible.0016_multi_vault.sql· up+down round-trips· 5 assertions
- Pass Existing single-vault rows migrate untouched.registry.migrate.test.ts:41· 4 assertions
Receipts
Receipts, not status updates.
Every unit of work produces a test receipt — per-criterion verdicts with falsifiable evidence and verification commands you can run yourself. Not a green check. A document you can open, and disprove.
— all minted from real construction, not written for the brochure.
§ 01 The anatomy, in motion 30.44° N
One receipt, printing itself.
A real receipt from this factory's own construction, minted line by line the way every unit of work produces one — an agent verifies, a human ratifies, and the record prints. Watch the anatomy assemble; the legend names each part as it lands. Hit Print another for a different specimen — one is an honest Partial, on purpose.
Every unit of work prints one of these. 89 exist. None are decorative.
- 1
The header
Receipt id, the story it verifies, the date, and the exact branch and commit. A receipt is pinned to one point in history — you can check it out.
- 2
Acceptance criteria
One row per claim. Each verdict points at a file and line, a named test, and how many assertions ran. Hover a row — the evidence is there to be disproved.
- 3
The verdict
A tally you can reconcile against the rows above — not a blanket "done". Ten of eleven would say so, in the same place; one specimen here is a Partial, and names the criterion it deferred.
- 4
Run it yourself
The exact commands, typed out and copyable. Run them against the same commit and get the same result — or don't, and you've found something.
- 5
Surprises
Institutional memory — what the build taught us that the plan didn't know. Even "no surprises" is worth saying; the silence is a claim too.
- 6
The tear
The receipt detaches into a physical artifact and the machine keeps the perforated stub. A unit of work — finished, verified, and filed.
§ 02 The stream 31.20° N
Not one receipt. A ledger of them.
Different work, same shape. Schema migrations, auth, UI, tooling — each unit of work leaves the same falsifiable record. One below is a Partial, on purpose: a story that shipped what it could and said what it didn't.
- Pass Roles & projects read off the JWT — no DB on the hot path.token.test.ts:88· claims decode· 6 assertions
- Pass Read-only grant is write-gated at the resource server.write-gate.test.ts:29· 4 assertions
- Pass Bundle renders the front-half intent → ideation chain.bundle-view.spec.ts:52· 5 assertions
- Skipped Mobile breakpoint for the bundle view.deferred to S-134 — out of this story's scope
- Pass Emits dist/planner only from the allowlist.build-planner.mjs:41· 6 assertions
- Pass Non-allowlisted targets are refused, not dropped.build-planner.test.mjs:70· 3 assertions
- Pass Bearer tokens verified via jose, three-way branch.mcp.verify.test.ts:47· 9 assertions
- Pass Expired / wrong-audience tokens rejected (deny by default).mcp.verify.test.ts:71· 5 assertions
The live site streams these continuously off the work ledger — each one a permalink like /receipts/T-125. Shown here: five of eighty-nine.
§ 03 The schema 31.98° N
The receipt is a contract.
A receipt isn't prose we format nicely. It's a typed object with a published schema — so it renders the same everywhere, and so anything can read it.
- verdict is an enum — pass · partial · fail. No prose "mostly done".
- evidence is structured — file, line, test, assertion count.
- surprises may be empty — but it is never omitted.
Published so your own tooling — or your own agents — can consume our receipts.
{ "$id": "https://oasisfactory.com/receipts/schema", "title": "Test Receipt", "type": "object", "required": ["id", "story", "verdict", "criteria"], "properties": { "id": { "type": "string", "pattern": "^T-\d+$" }, "story": { "type": "string", "pattern": "^S-\d+$" }, "verdict": { "enum": ["pass", "partial", "fail"] }, "criteria": { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/criterion" } }, "commands": { "type": "array", "items": { "type": "string" }, // copy-pasteable — the reader reproduces the verdict }, "surprises": { "type": "array", "items": { "type": "string" }, // may be empty; never omitted } }, "$defs": { "criterion": { "required": ["statement", "verdict", "evidence"], "properties": { "statement": { "type": "string" }, "verdict": { "enum": ["pass", "fail", "skipped"] }, "evidence": { "file": "string", "line": "integer", "test": "string", "assertions": "integer" }, "skip_reason": { "type": ["string", "null"] } } } } }
§ 04 Why it works 32.71° N
Three reasons a receipt is worth more than a status update.
A status update asks for your trust. A receipt hands you the means to withhold it.
FalsifiableEvidence, not vibes
Every verdict cites a file, a line, and a named test. There's nothing to take on faith, because there's always something to open.
RunnableCommands, not screenshots
The verification is a command you can paste. Run it against the same commit and get the same result — or don't, and you've found something.
AccumulatedA moat of eighty-nine
Each receipt is minted at build time, against the commit that produced it. No one retrofits this — you can't back-fill evidence for work already shipped.
§ 05 Audit 33.50° N
Don't take the method on faith.
Read the construction record of the system that built itself — every arc, every story, every receipt, in the same substrate this page describes. If the receipts don't hold, you'll be the one to catch it.