Every Fusion run is graded against a contract that was written down and frozen before the build started. We call it the Definition of Good, and it is the single most load-bearing object in the system: the judges read it, the gate executes it, the receipt reports against it, and billing keys off it.

What goes in the contract

A Definition of Good is a short list of criteria. Each one carries two labels:

  • How it is checked. Some criteria are executable: a test suite, a build, a static check the machine runs on its own. Others need judgment: readability, fidelity to the spec's intent, design taste. Those are marked for manual or jury review.
  • How much it matters. A hard criterion can fail the run by itself. A soft criterion shapes the verdict but cannot sink it alone.

A sketch of what that looks like:

definition_of_good:
  - id: DoG-1
    check: static_check      # the machine runs this
    weight: hard             # failing this fails the run
    text: "next build passes with zero errors"
  - id: DoG-2
    check: manual_review     # a judge grades this
    weight: hard
    text: "no data leaves the org boundary in any code path"
  - id: DoG-3
    check: manual_review
    weight: soft
    text: "naming follows the existing conventions in the module"

Why freezing matters

The contract is frozen before any candidate writes code, and it does not move during the run. This kills the two classic failure modes of AI evaluation:

  1. Grading on vibes. If the criteria are written after seeing the output, the output defines the standard. Frozen criteria mean the standard defines the output.
  2. Moving the goalposts. No candidate, judge, or integrator can renegotiate the contract mid-run. If the contract itself was wrong, that is a new run with a new contract, and the receipt says so.

Hard criteria drive the verdict

The verdict rule is mechanical on purpose: a run earns verified only when the objective gate passed and every hard criterion is satisfied or explicitly waived by a human. Soft criteria inform the jury's ranking but cannot flip a fail into a pass.

That mechanical rule is what makes the receipt worth anything. When the receipt says the run met its Definition of Good, you can open the contract and check every line yourself. Nothing in the verdict asks you to trust anyone's mood on the day.

Writing good criteria is a skill

The failure mode to avoid is the untestable wish: "code should be clean." A useful criterion names an observable: what command runs, what output counts as passing, what boundary must not be crossed. When we catch ourselves writing a wish, we ask what evidence would prove it, then write the evidence requirement down instead.

The contract is short, the discipline is real, and everything downstream in Fusion depends on it.

Source ledger

  • Fusion planning model, sections 8 and 9.
  • PR workflow, contract insertion points.
  • Fusion MVP PRD, FR-10 and FR-31a.