What a Fusion receipt actually proves
A Verified Receipt means an objective gate executed and every hard criterion of a frozen contract passed, with evidence pinned to the exact commit. Not a summary, not a vibe: a checkable record.
A Verified Receipt means an objective gate executed and every hard criterion of a frozen contract passed, with evidence pinned to the exact commit. Not a summary, not a vibe: a checkable record.
Planning work cannot pass an execution gate, so Fusion issues an Accepted Receipt instead of a Verified one. The ladder of commitment says exactly how much proof stands behind each artifact.
A Fusion Receipt gives every frozen criterion its own evidence row spanning six stages: gate, jury pass 1, Integrator disposition, jury pass 2, QA, and final status. The row follows one promise across the whole run without hiding absent proof.
Every run produces a manifest: the contract, the verdicts, the gate result, and the decision. Four fields tell you most of what you need before you open a single diff.
Verification can establish that a result is ready to ship. It cannot truthfully say the result shipped until a human authorizes the remote action and Fusion records durable delivery evidence afterward.
Verified versus accepted says whether the work met its contract. Customer-attested versus Fusion-attested says who controlled the machine that produced the evidence. Two questions, two fields, never one enum.
Verified is a narrow, earned state: the frozen Definition of Good was met and the evidence exists. If a hard criterion, required gate, or required evidence is missing or unparseable, the run is not Verified. Ambiguity resolves against us; waivers stay visible on the Receipt.