SYS.11 / PIPELINE
The pipeline
Sixteen steps over one snapshot. Eleven of them never consult a model.
The steps
What each one produces, and how it reaches its answer.
| Step | Produces | How |
|---|---|---|
| READ_REPOSITORY | The file index and content-addressed blobs | deterministic |
| COMPUTE_CHANGESET | What changed against the previous snapshot | deterministic |
| MAP_STRUCTURE | Directories, file classification, the shape of the tree | deterministic |
| DETECT_TECHNOLOGY | Languages, frameworks and versions, each with evidence | deterministic |
| UNDERSTAND_ARCHITECTURE | Module boundaries, the module graph, an inferred style | deterministic |
| MAP_DEPENDENCIES | Import edges and a per-file importance ranking | deterministic |
| BUILD_GRAPH | The knowledge graph — nodes and edges from the parsed source | deterministic |
| CLUSTER_GRAPH | Subsystems, hubs, cycles | deterministic |
| RENDER_GRAPH_VIEWS | The precomputed layouts the four tabs draw | deterministic |
| RUN_FINDINGS | Detector verdicts across six pillars | deterministic |
| EVALUATE_CONSTRAINTS | One result per enabled constraint, and the set outcome | deterministic |
| BUILD_INTELLIGENCE | The structured understanding of the project | reasoning |
| CREATE_CONSTITUTION | The project rulebook | reasoning |
| GENERATE_SKILLS | One Skill per role the project justifies | reasoning |
| REVIEW_SKILLS | A separate critique of each Skill, and a repair when it is weak | reasoning |
| SCAN_SKILLS | The security audit of the Skills this run wrote | deterministic |
The listed order is not the execution order
And the screen says so rather than drawing the list as a timeline.
Steps were appended to the list as they were built, and their position in it is written into every historical run at queue time. Renumbering would rewrite what an old row means, so the list stayed put and the execution order moved.
- READ · CHANGESETPARSED
The change set is derived from the file inventory and nothing else, so it runs second.
- STRUCTURE → DEPENDENCIESPARSED
The deterministic scan: one parse pass feeding three steps, because re-reading the tree three times triples the work for nothing.
- GRAPH → FINDINGS → CONSTRAINTSPARSED
All three — the graph, the findings and the constraints — read what the scan stored. They run before the reasoning layer, so an account with no provider still gets them.
- INTELLIGENCE → CONSTITUTION → SKILLS → REVIEWREASONED
The reasoning layer, each step reading the structured output of the one before it.
- SCAN_SKILLSGATE
The audit of what was just written. Deterministic, and it runs on every plan.
What happens when a step fails
A failed step is a failed step. It is never drawn as a zero.
- Each step is a retryable job with its own timeout, progress and idempotency key. Re-running a step is safe and converges on the same result rather than doubling anything.
- A step with no dependents that fails does not stop the run. Its absence is recorded, and everything derived from it reports that it could not be established.
- Steps that do not exist for your plan are rendered as not built, never as pending work somebody is waiting on.
- A detector that failed produced no verdict of any kind, and its silence means nothing. Counts derived from it are floors, and say so.
Running without a model
Eleven of sixteen steps have nothing to ask one.
If no AI provider is reachable, the deterministic steps still run to completion and the reasoning steps report that they could not. You get the structural map, the dependency graph, the findings, the constraints and the change set — and the parts that need a model say plainly that they were not produced.
Which model runs is a per-task setting, described in Models and routing.