How I build · The delivery method

The one idea. The model builds; the human specifies, reviews and signs. Every phase passes through gates, and a gate has two outcomes only: approved or revise. A revise returns to the artefact. It does not proceed "with the finding noted".

Reading path. Entry from The harness, the case study. The rules and hooks that hold these gates in place are on How I build · The harness; the documents the gates read and write are on How I build · The artefact set; the operating documents that run each session, and what happens when they drift, are on How I build · The operating model; what changed between the planned and the built system is on a later How I build page, Plan versus as built. The method was built on a sovereign OSINT platform built for a defence innovation challenge, and went unchanged to a second product, MyWarren.

It is written down as one SOP of about 66 KB in twelve parts: definitions, bootstrap, then a contract each for the session, delivery, memory, economics, enforcement and delegation, a failure catalogue, how to scale it down, what it is not, and a one-page reference card. This page covers the session and delivery contracts. The SOP itself stays private; what follows describes it.

1 · Three gates before the first action

Every session answers three questions out loud before it does anything substantive. Each is independent: a session can pass one and fail another.

The scope-shape test. Self-contained work — it extends existing structures, adds no unproven component, has no unresolved external dependency — is specified and built in one pass; splitting it only re-derives context. Risk-heavy work — a new component whose behaviour must be validated, an open licensing or availability question, or a measurement that everything downstream will be designed against — is specified, its open risk resolved, and stopped for review, even when the budget is ample. The cost being avoided is not tokens. It is an implementation built on an assumption that scoping alone might have overturned.

Two rules follow from the model gate. Decide at the gate, not mid-flight: switching model partway pays the context handover twice and lands the new model inside reasoning it did not build. Name a mixed session's split rather than averaging it: mechanical breadth goes to a sub-agent on a cheaper model, and the judgement stays in the main thread.

This site runs two of the three: the budget gate was dropped here by decision on 2026-10-18, and the scope-shape and model gates still open every session. This page was scoped as writing from files already on disk and given to the strongest model, because a wrong claim here would be caught by a reader, not by a test. Its build log is a later How I build page.

2 · The phase spec, written before any code

Every phase gets a written specification before any code is written. That is what makes a wrong decision cheap: it is caught while it is still a paragraph. One master scope document per milestone pins the component order, the phase sequence, the non-functional framework and the evaluation gates; each phase spec draws from it and does not repeat it.

The phase spec has a fixed skeleton:

The skeleton is a download: Phase spec skeleton, headings and field lists only, beside the five on The artefact set §4.

Two recording rules carry more weight than they look:

• Non-functional targets are declared before the build starts. Declared afterwards, they are set to whatever was achieved.
• A spec is never written to justify work already done. If the work outran its spec, the progress log says so, and the spec is written for what remains.

What a written floor did, measured. On the OSINT build, the credibility engine's band-agreement floor is 85.9 % and its measured agreement 94.4 %. The floor is encoded in a gate script, and that script blocked a proposed change costing 6.6 %. Measuring the generation layer's latency showed prefill at 78 % of it, and the retrieved context was cut from 8 × 900 to 6 × 700 characters in response.

3 · Review by role, before the human sees anything

A specification reviewed only by whoever drafted it, and then by the human, has had one pass — while the code that implements it gets a dedicated review. That is backwards: a wrong decision is cheapest to fix as a paragraph and most expensive as a schema with data in it.

So review roles are assigned per artefact type, not per person. Even with one human, the roles catch different things, and separate passes with separate framing find more than one pass wearing every hat.

The roles are staffed by sub-agents, each with its own framing and a narrow write scope. On the OSINT build these were a spec drafter, a test lead, a code reviewer and an end-user subject-matter expert (The harness §3). The gate runs before the human sees the artefact: the human is the last gate, not the first reviewer, because theirs is the scarcest time in the process.

The whole loop, from the pinned master spec to the retrospective:

The phase-gate diagram and the sign-off log form are offered as skeletons on The artefact set §4.

4 · Sign-off needs three things

A phase is not done until all three hold:

1. An end-to-end test exercises the new deliverable against the live system — idempotent and re-runnable, extending the existing check script or adding one for the phase.
2. The live outcome is demonstrated with real data the approver can see — query output, a rendered page, a message on a queue. Not a description of it.
3. The approver explicitly approves.

Until then the status reads built, awaiting sign-off — never complete — and the item sits in a standing index, because items in limbo otherwise become invisible.

Two rules keep the protocol honest. "Blocked" is not the default when the approver is away: the actual dependency footprint of the check is examined first, and most checks need far less than the full environment. Hand-seeded data is declared as such: a screenshot of hand-seeded data proves the page, not the pipeline that would normally fill it.

What a binary gate did, measured. The generation layer's gate required citation validity of 100 % (43 of 43) and abstention on 12 of 12 unanswerable questions. A smaller candidate model was rejected at the gate, abstaining on 9 of 12: a pass or a fail, not a trade-off argued in review. Across the OSINT build: 45 phase specs, 29 phase sign-off tags, and 1,711 tests passing on 2026-08-28.

5 · Measured versus projected, never blurred

Two ladders, kept apart:

• Every performance number is recorded as measured — a real run, at a stated scale — or projected — a capacity model, labelled as one. A projected number is never quoted as a benchmark.
• Development-scale and production-scale figures stay separate. A demonstration claim never silently substitutes one for the other.
• No production-scale throughput is quoted until a staged load test has produced it — the load stepped up and the curve shown.
• Targets that are out of scope for now are not dropped. They stay in the spec as production gates.

The rule applied to this page's own figures:

6 · Stated honestly

• One human holds the last seat at every gate. The person who writes the master spec also reviews and signs. The role-shaped passes reduce what reaches that person; they do not make the sign-off independent.
• The OSINT build's reviewers were scoped by prose. Each sub-agent's write scope was stated in its instructions, not enforced, and the code reviewer's "do not edit" is a prose rule (The harness §3 and the diagram above). Later projects moved scope into tool lists and hooks.
• 1,711 is a count of tests, not of coverage. The adversarial quadrant had 0 tests, and retrieval quality has no eval yet (The artefact set §5).
• The SOP is the method as written. It went to the second product unchanged; how fully each gate ran there is told with MyWarren, not here.
• 45 specs and 29 sign-off tags are not the same population. The difference is not broken down on this page.

Measured figures on this page

What this page does not claim

• No count of code reviews or RCAs. The code-review count differs between two sources, and the RCA count is not yet cleared for quotation; neither is quoted until both are reconciled.
• No savings ratio. Spend and estimated scope sit side by side; no multiple of cost or duration is claimed.
• No claim that every project ran every gate in full. The loop is the OSINT build's; other projects run it in some form.
• No claim that the eval gate ran in CI. It is a script that encodes the floor.
• The SOP is not reproduced. Its gates, roles and spec headings are described and re-typed; its text stays private.