A review claim in Fusion is backed by execution. When a judge says a change is sound, the claim rests on scanners and tests that actually ran against that change, and the verdict cites their output. Reading the diff is not evidence on its own; it is where the evidence gathering starts.
That rule sounds obvious until you look at how most review works, human or automated. A reviewer reads, forms an impression, and writes the impression down. The impression is often right. But nothing in the artifact separates a correct impression from a confident wrong one. So we built the review pillar around a stricter standard.
A claim you can run beats a claim you can only read.
Impressions get downgraded
In a Fusion run, verdicts cite command output, not impressions. A judge who believes a change breaks something has to point at something that ran: a test that failed, a scanner that flagged the line, a command that exited nonzero. A finding that cannot be reproduced by running something is downgraded. It stays in the record, but it reads as opinion, and opinion does not decide a criterion.
This cuts both ways, which is the part people miss. It disciplines the negative claims, so a vague "this looks risky" cannot block a merge by itself. And it disciplines the positive ones, so a cheerful "looks good to me" cannot wave a change through either. Both sides of the argument have to show their work, and the work has to be executable.
"Review passed" is a list of exit states
The contract every run is judged against, the Definition of Good, has an executable half: literally commands with pass/fail exit states. The consequence for review is precise. When a receipt says review passed, it means these commands ran and they passed. Not that a model read the diff and produced a paragraph of approval.
| The claim | What backs it |
|---|---|
| "Looks correct to me" | An impression of the diff |
| "Tests pass" | Test commands that ran and exited clean |
| "Scanner is clean" | Scanner output against this exact change |
The left column is what review has historically shipped. The right column is what a receipt carries.
No evidence, no Verified
Fail-closed applies here too. If the evidence cannot be produced (the command will not run, the environment will not stand up, the scanner cannot reach the code), the claim does not ship as Verified. It does not degrade into a softer "probably fine". The absence of proof is treated as the absence of a pass, the same way it is treated everywhere else in the harness; we covered the general rule in Verified fails closed.
Review starts from a pull request
None of this requires a Fusion build to exist first. The review pillar starts from an existing pull request rather than a new build intent, and it freezes a review projection of the same RunSpec protocol: target revision, compatibility boundary, required scanners, and decision policy. The design goal is to reduce attention cost, not add another comment stream.
Evidence strength decides the finding label. A reproducible bug with a failing test can be verified. Independent reviewer agreement without an executable reproduction can be consensus. A plausible concern that still needs human judgment remains flagged. Those labels help a maintainer decide where to spend attention; they do not turn advisory review into an automatic merge authority.
Several reviewers may report the same root cause through different symptoms. Fusion groups and deduplicates those findings, then carries the strongest evidence and dissent forward. The output is a decision surface, not a wall of independent bot comments.
Where this goes next
We want the executable share of review to keep growing. Every criterion that today needs a judge's reading is a candidate for a command tomorrow: a reproduction script instead of a description, a failing test instead of a warning. The end state we are building toward is a review verdict you can re-run on your own machine and get the same answer, because the answer was never anyone's opinion in the first place.
Source ledger
- PR workflow, sections 1–5.
- Fusion MVP PRD, FR-21, FR-22, FR-22a, and FR-22b.