Why Fusion spends more tokens on purpose
Fusion uses more AI sessions than a single-agent build. Our own runs show what that extra verification caught, where it helped, and when one builder is the better buy.
topic · trust
Why the best AI-written code still needs an independent adversary
The first AI coding agents usually produced credible implementations. The biggest improvement came when fresh reviewers challenged the work, combined the best ideas, and tested the finished result through paths the builders missed.
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.
Why we run judges from three different vendors
A jury drawn from rival model vendors breaks family bias: a model grading its sibling's homework is a conflict of interest. Cross-vendor votes, blind packets, and preserved dissent make the verdict neutral.
Why candidates cannot rewrite the test that grades them
A candidate can change implementation files, but it cannot redefine the protected checks that decide whether the result passed. Fusion restores gate-feeding inputs from the pinned base, verifies their fingerprints, then runs the objective command against the candidate SHA.
Failure should be a typed state
"Failed" is too small a word for a verification run. Fusion records typed stop states so the operator can distinguish bad code, stale evidence, jury contention, infrastructure failure, and a retryable publication problem. Each stop state needs a different recovery route.
Why Fusion does not auto-merge
Fusion's review can inspect an existing pull request, publish findings, and prepare bounded repair commits. It cannot silently cross into merge, release, or deployment authority. Repository owners keep the final mutation decision.
Verified is not shipped
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.
The exam grade and the proctor
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.
Local-first: what stays on your machine, and when
By default a Fusion run executes on your machine or in your CI: code and model keys stay inside your chosen trust boundary while the control plane coordinates and stores receipts. Managed execution exists, but it is an explicit choice.
Why we never guess which model wrote the code
Model identity comes from one place: the roster assignment the run lead records in the manifest before the run starts. We never reconstruct it from branch names, commit style, or output feel.
Failed runs are free
A run that misses its frozen Definition of Good is not billable. The failure still lands on a receipt; you just do not pay. Why we wired billing this way.
Blind judging: what the jury sees, and what it can't
Fusion judges never learn which agent wrote which candidate. Packets are stripped of identity and independently randomized per judge, so verdicts attach to the work, not the brand.
Verified fails closed
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.
Trust is the bottleneck now
AI made code cheap to produce and expensive to trust. The fix is not a better generator; it is a verification layer that proves what survived.