Why the decisions are in Python Shipped
Scope resolution, signal matching, merge keys, loop stopping rules — every decision that can be made deterministically is, and none of them is re-derived by a model.
A model asked the same question twice can answer differently, and a pipeline whose control flow is model-decided is one whose behaviour cannot be tested. So the split is drawn hard: models produce findings and prose, and Python decides what happens next. Which specialists are eligible, which findings are the same defect, whether the build loop continues — all deterministic, all covered by tests.
The build loop is the clearest case
A recorder compares this iteration's criterion statuses against every prior one and returns a next action the driver executes verbatim: finish_ready, continue, rerun_gate, reset_and_retry, retarget_unjudged, escalate_once, or halt with a reason. The halt ordering is fixed — done, then oscillating, then budget, then the iteration backstop — so two halts that both apply always resolve the same way. A model that was asked "should we keep going?" could not offer that guarantee.
And it is what makes the failures legible
When a run halts, the reason is a value from a fixed set rather than a paragraph. That is why the failure record on this site can be specific about which runs stopped and why.