Skip to content

The Verification Spine

Agents generate. Flow-Next proves.

Every stage of the pipeline leaves an artifact that the next stage - or a human, six months later - can audit. That is not a feature list; it is one system with one bias: verification. This page names the system, shows its parts, and explains why it is built this way.

The industry’s numbers describe a paradox: 96% of developers do not fully trust that AI-generated code is functionally correct, yet only 48% always verify it before committing (Sonar, 1,100+ developers surveyed). Everyone knows generated code needs checking; half of everyone actually checks. The gap between the two is where production incidents come from.

Flow-Next’s answer is structural, not motivational. The harness does not remind you to verify - it refuses to advance without proof. A task cannot complete without evidence. A review cannot pass without a verdict artifact. A merge cannot happen on narration alone. The missing half of the Sonar stat is operationalized instead of exhorted.

“Bias towards verification” did not appear from nowhere. It sits on a line of thought the field has been converging on:

  • Jason Wei’s verifier’s law - the observation that tasks easy to verify get solved by AI first, because verification asymmetry is what makes training and trusting a system tractable. Flow-Next applies the law in reverse: make every stage of engineering easy to verify - receipts, numbered criteria, evidence files - and agents become trustworthy on it sooner.
  • Andrej Karpathy’s generation-verification loop - his framing that humans and agents alternate generation and verification, and the product’s job is to make verification fast - plus his autonomy slider: give up autonomy only as fast as verification keeps up. Flow-Next’s autonomy dial is that slider made concrete, with the same gates at every rung.
  • Werner Vogels’ “verification debt” - his re:Invent 2025 warning that AI generates code faster than teams comprehend it, and the unreviewed remainder accrues like technical debt. Receipts and evidence JSON are amortization: the debt is paid per stage, never rolled over.
  • Sonar’s verification gap - the 96/48 stat pair above: distrust without verification as the industry’s default state.
  • Simon Willison’s “code proven to work” - his rule that your job is to deliver code you have proven to work, because shipping unproven code shifts the real work onto whoever reviews it. Flow-Next generalizes the rule from the person to the pipeline: every handover ships with its proof attached.

Flow-Next’s contribution is not the diagnosis - these five made it - but the working system: a pipeline where the verifying is done by construction.

The gates below are handover checkpoints - proof that changes hands between stages. But verification does not wait for a handover: it starts while the implementation agent is still typing.

Every spec carries numbered acceptance criteria (R1, R2, …), and every task declares which ones it satisfies (satisfies: [R1, R3]). That is not paperwork - it is the target the worker verifies against. Before it edits a single line, the worker runs the spec’s own commands to establish a green baseline, so “it passed” later means this change passed, not that it inherited a suite that was already broken. It fixes anything it breaks mid-implementation before continuing. And before it is allowed to claim the task done, it re-runs that exact suite itself - a fresh worker, re-anchored on the criteria, proving its own work with evidence, not asserting it in a summary.

This is the bias in its earliest form: the harness makes the implementer verify as it builds, against criteria written down before the build started. Everything below is the second line of defence.

Each stage’s proof is a file on disk, not a sentence in a transcript:

StageWhat must be provenArtifact
In-loop implementationA green baseline held; the change passes the spec’s own commandscaptured suite output → evidence JSON
Implementation reviewA cross-model reviewer issued SHIP.flow/review-receipts/<branch>.json
Task completionCommits, tests, and a done summary existevidence JSON required by flowctl done
Live-app QAThe running app actually behavesqa_verdict receipt; PASS by reading source is forbidden
MergeCI green, reviews convergedland’s gate tree - evidence over narration
Quality gatesThe exact suite passed at the exact commitgreen receipts keyed to commit SHA + command hash

Evidence is self-run; the verdict never is. The implementer verifies its own work mechanically - it runs the suite, checks the baseline, gathers the evidence. What it never does is grade it: the model that wrote the diff never issues its own SHIP. Reviews are cross-model by construction - a different model family reads the change blind, so the writer’s blind spots and the reviewer’s blind spots do not overlap. QA goes further: the skill is structurally forbidden from marking PASS by reading source code, because an implementer’s narration of correctness is exactly the thing that needs checking. Running the tests is evidence; declaring the work good is a judgment - and only the first is the author’s to make.

Evidence over narration. Agents narrate confidently; the pipeline is built to ignore that. flowctl done rejects completion without evidence JSON. Land merges on CI state and converged review threads, never on an agent’s summary of them. Where a claim can be a file, Flow-Next makes it a file.

Interactively, a human can eyeball every step. On autonomous loops, nobody is watching a given tick - so the loop’s safety is the spine: pilot advances on verdicts, Ralph transitions on receipts, land merges on evidence. The same gates fire at every autonomy rung; the dial changes who is present, never what is proven.