The sequence, and the loop around it

How it actually flows

The stages below are the machinery, and they do run in order. What they are not is the shape of the thing: an opportunity is framed by the front end, argued over by seven chairs who each know something the others do not, and changed in shape when a statement it rested on turns out to be false. This page draws the arrows a stage table cannot — the front-end loop that wraps all of it, and every place the contracts send a candidate backward before a human ever sees it.

The loop the stages sit inside

The front end owns the opportunity and owns none of the expertise. It writes down what the opportunity rests on — the assumption register, a subset of the claims, each with who depends on it and what breaks if it is false — then convenes the chairs. Each returns a position: a verdict, the conditions that would change it, and the requests it raises. Conditions become unverified claims, and go to the Verifier like everything else.

Loop — a statement fails: when a registered claim comes back refuted or unconfirmed, an impact review fires — who depended on it, what it costs, and one of exactly three outcomes: absorb (nothing load-bearing depended on it), pivot (the opportunity changes shape, with lineage and a lesson), or commission (the work that would settle it gets raised). There is deliberately no fourth outcome; "note it and carry on" is what the register exists to make impossible, and check_loop.py refuses a loop record that tries it.
Loop — a pivot re-opens the round table: a pivot bumps pivot: in the loop record, and every position written against the old shape shows as stale until that chair answers again. Chairs disagreeing in writing is the output, not a problem to resolve — and no chair holds a veto: blocks opens an impact review, and killing stays Stage 5 arithmetic over verified claims.

Four more loops sit inside and around the stages, and none of them are new — they are stated in the department contracts already.

The pre-gate loop

Stage 0Scout
→
Stage 0.5Seed Scout
→
Stage 1Generator
→
Stage 2Scorer · draft
→
Stage 3Verifier
→
Stage 4Scorer · verified
→
Stage 5Gate check
→
Stage 5.5Wrap
Loop — under 6/9 verified factors: Stage 5 writes queued-research instead of a kill. 45_research builds more dossier, drafts more claims, and hands back to Verify → Rescore → Gate-check — the same three stages run again on the same candidate. departments/45_research/CONTEXT.md names this explicitly as "the loop that actually turns research into coverage."
Loop — a kill isn't the end either: when Stage 5 does fire a kill, the Librarian logs it with a named revive condition, and 00_scouting watches every future scan for exactly that condition. A fired one reopens the idea at Stage 1 — a second loop that never touches a human at all.

The human boundary, and the long loop after it

Stage 6Human shortlist
→
Stage 7Diligence
→
Stage 8Outcome logged
Loop — the flywheel itself: Stage 8's outcome feeds back into 00_scouting (what to watch for) and 10_front-end (what to try next). The root CONTEXT.md states this in one line: "Stage 8 feeds Stages 0 and 1." It is the loop the whole repo is named for, and it is the only one that spans the Tier 3 boundary.

The on-demand loop

80_commercial adds another: an unfillable market-model leg is filed as a research row (source_of_question: commercial-gap), and once 45_research promotes a report against it, the model is rebuilt with a real leg instead of an assumption. It isn't tied to a stage number because /market-model itself isn't chained — running it is "a decision about where to spend effort," same as /research and /wrap (departments/CONTEXT.md).

What's still genuinely linear

The request ledger generalises that on-demand loop to every pair of departments: any one may ask any other a question it cannot answer itself, the answer must name an artifact that exists, and referred-out records an opportunity leaving the front end entirely for M&A, an R&D programme or a partner. What remains genuinely linear is narrower, and worth naming rather than smoothing over: Stage 3 has no automatic trigger back into 45_research when a candidate comes back mostly unconfirmed rather than failing the 6/9 floor outright. The path exists — a human or an agent can run /research on it at any time — but nothing makes that happen on its own between Stage 4 and Stage 5. That is a considered omission, not an oversight: the same contract that defines the queued-research loop also lists /research among the commands /flywheel-cycle deliberately does not chain, because which candidate deserves a research pass is a decision about where to spend effort, not a mechanical step every candidate should get automatically.

Inside each block

What the sequence diagram above compresses into one box per stage. Each list is drawn from that department's own ## Process section — see Departments for the full contract, inputs and outputs each one carries.

00_scouting · stage 0 · /scan

  1. /scan launches the Scout
  2. Sweep connectors for changed facts — clearances, recalls, patents, codes, policy, literature
  3. Log the diff: what changed and which candidates it touches — never a score, never a tag
  4. Librarian routes affected candidates back to Stage 2 for re-scoring

05_macro-trends · stage 0.5 · /seed-scan

  1. /seed-scan opens one of ten lanes, or re-checks a watchlist entry
  2. Anchors (dated sources), a direction, and a quarantined extrapolation — never merged
  3. A counter-anchor section and a runnable falsifier are required, not optional
  4. The seed becomes steer for Stage 1 — read whenever generation runs, never auto-chained

10_front-end · stage 1, and the loop · /generate, /front-end-loop, /round-table, /impact, /pivot

  1. /generate launches the Generator, primed with the rubric and the killed-idea log
  2. Copy the template; fill device class, target, mechanism, closest predicate
  3. Write every line of ## Claims as unverified — no scores, no verification yet
  4. Check the killed-idea log first — no re-proposing a dead shape without a fired revive condition

20_scoring · stage 2, 4 · /score, /rescore

  1. Stage 2: score unverified claims for triage only — no number here is final
  2. Gate A: worth the cost of a Verifier pass? A judgment call; a skip must be named
  3. Stage 4: recompute the composite from verified claims only, after Stage 3 runs
  4. Under 6/9 factors verified → stage: verifying, queued for another pass, not finished

30_verification · stage 3 · /verify

  1. /verify launches the Verifier in a fresh, structurally separate context
  2. Route each claim by type to its typed connector — never a generic web search
  3. Set the tag in place — verified / unconfirmed / refuted — citing the connector's record
  4. A jurisdiction with no connector stays unconfirmed — never answered with the wrong regime's evidence

45_research · stage 4.5 · /research, /research-fleet

  1. /research or /research-fleet builds or refreshes a domain dossier
  2. Draft unverified claims from the sourced material — a dossier itself carries no tags
  3. Hand back to Verify → Rescore → Gate-check — the loop that turns research into coverage
  4. Also works rows 80_commercial commissions when a market-model leg has nothing under it

50_gate · stage 5, 5.5 · /gate-check, /wrap

  1. /gate-check: apply the kill floors to the Verified Composite, never Stage 2's draft
  2. Under 6/9 factors verified → queued-research, not a kill — looped back to 45_research
  3. A kill fires → the Librarian logs it with a revive condition Stage 0 watches for
  4. /wrap: complete the seven wrap criteria and write the ## Wrap section

60_human-review · stage 6, 7, 8 · /shortlist, /diligence, /log-outcome

  1. /shortlist compiles every wrapped candidate, led by evidence coverage — ranks nothing
  2. A human decides: approve, reject, or defer — recorded only by a person, never an agent
  3. Approved → /diligence: bench evidence, failure modes, a draft FTO memo — drafts, never sign-off
  4. A real outcome, once known, is logged via /log-outcome and feeds the calibration log

80_commercial · stage — · /market-model, /business-case

  1. /market-model: state the chain first, then run the checkable primitives under each leg
  2. Type every gap — draftable, researchable (filed to 45_research), or a declared assumption
  3. Report a band and a span with a coverage line; refuse a point estimate and a chosen scenario
  4. /business-case: who pays, from which budget, 2-4 routes to revenue, each with a kill condition

90_artifacts · stage — · /pitch-decks, /narrate

  1. /pitch-decks: three lenses, each slide a condition rather than a conclusion
  2. /narrate: synthesizes claims, dossier and decks into one story — no new facts introduced
  3. Renders review/ from the knowledge base — generated, never hand-edited
  4. Nothing here scores, gates, or touches stage: / status:

95_marketing · stage — · /messaging

  1. /messaging: reads the candidate cold, drafts investor / user / payer message sets
  2. Every line cites its claim and tag, or is marked [unsubstantiated]
  3. Anything beyond the stated intended use is named in its own section, not folded in
  4. Unsubstantiated lines get appended back to ## Claims as unverified
Generated from departments/*/CONTEXT.md, CONTEXT.md by engine/scripts/build_review.py on 2026-09-13. This page is a view — edit the source file and rebuild, never edit here.