Why AI crawlers are welcome here
This ledger allows AI crawlers on purpose. If an answer engine explains verification to someone, we want the explanation to be right and the citation to point here. llms.txt and agents.md make that easy.
the ledger
previous entries
page 02 / 04Reading a run manifest in ninety seconds
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.
Mode, profile, and roster: three knobs with different jobs
Mode, profile, and roster are independent controls. Mode decides who drives the workflow. Profile decides whether one builder or a tournament runs. Roster decides how many candidates, judges, and integrators participate and which engines fill those roles.
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.
Conductor, not kitchen
Fusion's hosted side coordinates runs, stores receipts, and publishes checks. By default it does not host your code or your keys. The conductor keeps time; the kitchens stay yours.
From intent to evidence: the five stages of a Fusion run
A Fusion run moves through Discovery, Plan, Build, Review, and Output. Each stage creates a different artifact, owns a different decision, and hands a narrower claim to the next stage.
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.
Tokens, not vibes: how we count what a run costs
Tokens are the primary unit for every engine in a run, metered per role: candidate lanes, judge seats, integrator, QA. Dollar figures from subscription CLIs are estimates. The usage record ships on the Receipt.
Depth is the meter
Fusion prices by verification depth: how many candidates compete, how many judges vote, how deep review goes. The meter is rigor, not tokens.
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.