Every Fusion run ends with a receipt. It is the artifact the whole system exists to produce, so it deserves a precise answer to a fair question: what does it actually prove?
The claim, in one sentence
A Verified Receipt proves that an objective gate executed against a specific commit, and that every hard criterion of a Definition of Good that was frozen before the work began was satisfied or explicitly waived by a named human.
Each load-bearing phrase is doing real work:
- Objective gate executed. Something ran: tests, builds, checks. Not "an AI read the diff and felt good about it." Where the run is planning-grade and nothing can execute, the receipt honestly downgrades itself to Accepted.
- Specific commit. The evidence is hashed and pinned to the exact commit it graded. Change the code afterward and the pin visibly no longer matches; the receipt cannot be quietly reused on work it never saw.
- Frozen before the work began. The standard could not bend itself around the output, because the standard predates the output.
- Hard criteria, satisfied or waived. The verdict rule is mechanical. And a waiver is not a loophole: it is a named person accepting a named risk, on the record, visible on the receipt forever.
What is on it
Five field groups, each answering one question:
| Field group | The question it answers |
|---|---|
| Roster | Which engine, provider, and model sat in each lane and judge seat, recorded before the run started |
| Verdicts | How each criterion of the frozen Definition of Good came out, per judge, per pass |
| Provenance | Which candidate each piece of the final came from, including grafts taken from losing candidates |
| Usage | What the run consumed, counted in tokens per role: candidates, judges, integrator, QA |
| Attestation | Who controlled the execution environment and where it ran |
Criteria name their proof
Consider a small feature request: add an export command without breaking existing output. Its proof contract could hold four criteria:
| Criterion | Required proof |
|---|---|
| Command exists | CLI integration test exits successfully |
| Output is valid | Schema validation passes against a fixed fixture |
| Existing behavior survives | Baseline regression suite stays green |
| Help text is clear | Blind jury checks the documented workflow |
The receipt preserves these rows. A reader can see whether every criterion passed, failed, was waived, or stayed unknown. A green summary cannot erase a red row.
What the receipt does not claim
A receipt is honest about its edges, because overclaiming is how trust products die:
- It does not claim the contract was complete. If nobody wrote "must not regress the login flow" into the criteria, the gate did not check it. The receipt proves the contract was met, and shows you the contract.
- It does not claim infallibility of judgment. Jury verdicts on manual criteria are recorded with their splits and dissents intact, so you can see exactly how confident the confidence is.
- It does not claim more about the environment than it knows. Where the run executed, and who controlled that machine, is recorded as its own field rather than smuggled into the word "verified".
Why this beats a review summary
The alternative artifact in this market is the AI review comment: a paragraph of prose attached to a pull request, unreproducible, unpinned, and unaccountable. It might be right. You cannot check whether it is right, and six months later you cannot even reconstruct what it looked at.
A receipt is built for the opposite fate. It is structured, so it can be read in ninety seconds or queried across a thousand runs. It is pinned, so it cannot drift away from the code it graded. It names its criteria, its verdicts, its waivers, and its dissents, so the person who merges on it can defend the merge later, to a lead, an auditor, or an incident review.
The receipt is the product
Everything else in Fusion, the rival candidates, the blind cross-vendor jury, the integrator, exists to make this one artifact strong enough to lean on. Code was already cheap. The receipt is the part you could not get before: proof that survives the person who vouched for it.
When someone asks what Fusion sells, this is the answer. Not code. Receipts.
Source ledger
- Traceable output bundle specification, sections 4 to 7.
- Fusion MVP PRD, FR-31 and FR-31a.
- FUS-6 Verified Receipt, five recorded criteria and two objective suites.