Lanes, Gates, and Loops

For Both Executive and Technical Readers

The Pipeline reads as eight linear steps. The more useful shape is a swimlane diagram: three lanes, three gates, three loops, and one of the three lanes is thinner than it should be.

The Pipeline is documented as eight numbered steps, Parse through Narrate, and that numbering is correct. It is also the wrong picture to hold in your head if the question is who does what. A numbered list makes every step look like the same kind of thing happening in the same kind of way. It is not. Some steps are language. Some are code. None of the documented steps are a human, and that omission is not an oversight, it is a real gap worth naming rather than papering over.

A workflow diagram, with lanes, gates, and loops, is the more honest shape. Lanes show who or what is doing the work at each point. Gates show where the pipeline certifies or refuses rather than passing through. Loops show where the straight line bends back on itself, to ask a clarifying question, to flag that the world has changed, or to feed a correction back in. All three exist today, scattered across a dozen pages. This page draws them as one picture.

Every step in the Pipeline belongs to exactly one of three lanes. Knowing which lane a step is in tells you what kind of failure to expect from it. The diagram below is the picture §01 promised.

LLM LANE CODE LANE HUMAN LANE: thinner, underspecified Parse & Formalize Steps 1–2 Narrate Step 8 Route Step 3 Identify Step 4 Compose Step 5 Execute Step 6 Audit Step 7 disambiguation + correction monitoring Scope Cards, signed in advance ◆ gate: certifies or refuses
The dashed border on the Human Lane is deliberate. It is drawn thinner because it is specified less rigorously than the other two, the subject of §05.
LLM Lane

Parse & Formalize (Steps 1–2) and Narrate (Step 8). The only two points where natural language crosses the boundary into the pipeline. Parse turns a question into a typed CausalQuery. Narrate turns a typed AuditRecord back into prose. Neither step reasons. Both are constrained to a fixed schema, so neither can produce free text where a typed object is expected.

Code Lane

Route (3), Identify (4), Compose (5), Execute (6), and Audit (7). No language model runs in this lane. Every step consumes a typed object and produces a typed object: a RouteResult, an IdentificationCertificate, a PosteriorResult, an AuditRecord. This lane is deterministic: the same inputs produce the same outputs, every time, which is what makes it auditable.

Human Lane

Not a pipeline step, because it is never documented as one, but present at every real boundary: the expert who answers a disambiguation question (Grammar §05), the expert who re-elicits a mechanism after a TrustAlert (Monitoring), the reviewer who signs a Scope Card (Deliverables). This lane carries real authority in the architecture and almost no formal description. Section 05 below is about that gap specifically.

A gate is a step that can refuse. Three of the Code Lane’s five steps are gates: each one either certifies that its condition holds, or emits a typed refusal and stops the pipeline there. No gate is optional and no gate can be talked past by a more confident-sounding answer.

GateCertifiesRefuses when
RouteA single model, or a composed set of models, covers the queryNo model or combination in the Registry covers the estimand; returns a RefusalObject naming the gap
IdentifyThe estimand is identifiable from the routed model, by back-door, front-door, or do-calculusNo identification strategy exists; “an answer that cannot show its certificate does not ship”
ComposeThe seam between two or more models satisfies the five conditions on ComposabilityConditional independence is violated at the seam; a composed answer would look valid and not be

The three gates run in sequence, and each one can only pass what the previous gate certified. A query that fails Route never reaches Identify. A query that fails Identify never reaches Compose or Execute. The refusal is not a failure state to be hidden. It is the gate doing its job.

A straight pipeline runs once and stops. These three points bend back rather than running straight through, and each closes a different kind of loop.

LoopFires whenCloses back at
DisambiguationParse cannot resolve which rung a question is asking about. It does not guess. It asks. The worked dialogue on Grammar §05 shows this firing on an ambiguous past-tense question.The stakeholder’s answer, back into Parse, same query, same session
MonitoringA standing likelihood monitor detects drift and issues a TrustAlert with a “re-elicit” or “suspend” verdict. Detailed on Monitoring.The Human Lane, an expert reviews the mechanism, not a bigger model, across all future queries until resolved
CorrectionEvery time the Disambiguation loop fires. That exchange becomes a labeled example: this phrasing, in this domain’s vocabulary, meant this rung. Argued for on Grammar §04.Parse’s own future behavior, cumulative, domain-specific, never wiped between sessions

The Correction loop is a decision-journal entry for the parsing step in the sense Timestamps are Required means it: dated, specific, and checked against what the classification should have been.

All three loops return control to a point earlier in the pipeline rather than producing a final answer. None of the three is optional in the sense that a well-run deployment could reasonably disable them; disabling any one of them is what turns a certified pipeline back into a system that guesses.

The Human Lane is real. It is where every Scope Card gets signed, where every disambiguation question gets answered, where every re-elicitation after a TrustAlert happens. It is also the least formally described lane of the three, and that is worth stating plainly rather than leaving implicit.

A fuller version of this lane would specify, with the same rigor the Code Lane already has: what a review certifies, whether a certificate can be sealed against further edits once a human has signed it, whether a human reviewer can override a gate’s refusal, and if so what artifact records that override happened and why. These are governance questions, not implementation questions, and they do not yet have a page. This is a real gap in the architecture as documented, not a rhetorical one.

Why This Matters More Than It Looks A pipeline whose Code Lane is rigorously specified and whose Human Lane is not can quietly become a system where a human’s override is less auditable than a machine’s refusal. That is backwards. The lane with the least specification should not be the lane with the most authority.

A provisional direction, not yet built: the natural artifact would be an OverrideCertificate, structured the same way every other certificate in this architecture is, a typed object naming who overrode which gate, on what stated basis, at what timestamp, attached to the AuditRecord alongside the refusal it overrode rather than replacing it. That keeps the Human Lane’s authority real while making it exactly as inspectable as the Code Lane’s. Nobody has specified this yet. It is the most concrete next step this page can point to.

This gap is also not unique to this page. The Organizational Challenge and Elicitation Challenge on Three Challenges, Not One are the same underlying gap seen from a different angle: both are places where a human’s judgment is doing real work that the architecture currently takes on faith rather than certifying.

One query, all three lanes, one gate refusing, one loop firing.

If we'd tightened underwriting last quarter, would losses have improved?
AnyChatLLM Lane · Parse · disambiguation loop
This reads like Rung 3, but could mean a policy question in generic clothing. Do you mean specifically last quarter's file, or would tightening underwriting help in general?
The general policy question.
AnyChatCode Lane · Route · gate
Routed to the underwriting model. Scope Card covers this population and this intervention. Proceeding to Identify.
Go ahead.
AnyChatLLM Lane · Narrate, reading the Code Lane’s AuditRecord
do(Underwriting = Tightened): expected losses fall 6.2%, offset by an estimated 2.1% drop in approved volume. Full certificate and evidence trail attached.

The disambiguation loop caught the ambiguity before Route ran. This exchange is now a candidate for the correction loop: the next stakeholder who phrases a similar question about a different repeatable action should not need to be asked twice.

This page draws a picture rather than adding a component. Every lane, gate, and loop here already has its own page: Pipeline for the step sequence, Parse and Narrate for the LLM Lane, Route, Identify, and Composability for the three gates, Grammar for the disambiguation and correction loops, and Monitoring for the standing loop. What did not exist before this page is the claim that these are three instances of the same pattern, and the naming of the gap in §05.

SkippedWhat it looks likeWhich lane, gate, or loop was actually at fault
Identify gate bypassed for latencyA posterior arrives with no IdentificationCertificate. It looks like every other answer. Nothing in the response itself signals that it should not have shipped.Code Lane, gate. The fault is not in Execute or Narrate, both did their job correctly on an estimand that was never certified identifiable.
Monitoring loop disabled to reduce alert volumeThe model keeps answering confidently for months. The mechanism it encodes has already drifted. Nothing about any single answer looks wrong.Human Lane, loop. The Code Lane is still executing correctly against a domain model nobody has re-elicited.
Re-elicitation verdict issued, never acted onA TrustAlert exists in the log, correctly flagging drift. The pipeline was never actually suspended or reviewed.Human Lane, the missing lane from §05. The Code Lane did exactly what it was supposed to; there is no artifact that certifies whether the recommended action was ever taken.

The third row is the one worth sitting with. It is not a bug in any documented step. It is a consequence of §05: there is currently no artifact that certifies a human acted on a loop’s recommendation, only one that certifies the loop fired.

The practical use of this page is diagnostic, same as Three Challenges, Not One: when something in a deployment feels wrong, asking which lane it happened in, whether a gate should have caught it, and whether a loop should have fired, is a faster way to find the actual fault than re-reading the eight-step list from the top.