What Is Risk-Band Routing in a Software Factory?

An autonomous software factory runs on trust, but trust needs a ceiling. The risk_tier_gate is where that ceiling gets enforced, and risk-band routing is the mechanism that makes the ceiling dynamic. It sorts every change into a risk band, low, medium, or high, and routes accordingly. High-band changes go to a human every time, regardless of what the autonomy tier says. This is not a recommendation. It is a circuit breaker.

The risk_tier_gate

The risk_tier_gate sits in the factory's core, alongside the oracle-strength floor check. Both run on every change before anything advances. The floor check asks: does the test suite still earn its autonomy? The risk-band check asks: regardless of the test suite, is this change too risky to trust to automation?

The gate reads Verdict.risk.band from the evidence bundle produced by the critic station. If the band is "high", the gate returns ROUTE_HUMAN immediately. No further checks. No override path. The reasoning is simple: some changes carry inherent risk that no test suite can fully address. A change to authentication logic, payment processing, or a compliance-sensitive path should not go lights-out even with a perfect mutation kill rate.

How Risk Bands Are Determined

The risk band comes from the RiskScore object in the evidence bundle. A risk scorer evaluates the change against a set of features: what paths does it touch, what data does it handle, what security boundaries does it cross. The scorer outputs a score and a band classification. Low-band changes follow standard routing. Medium-band changes may advance autonomously but face higher audit sampling rates. High-band changes always route to a human.

The band itself is a coarse classification by design. Fine-grained risk scores create an illusion of precision. Three bands force a decision: is this safe enough to automate, or is it not?

Sampling and Audit

Risk-band routing also drives the factory's audit sampling. The sampled_for_audit function uses the risk band to decide whether a change gets pulled into the human audit queue. Low-risk changes are spot-checked at a low rate. Medium-risk changes at a higher rate. High-risk changes are audited at 100%. This is statistical process control applied to governance. The sampling rates can widen automatically when the control chart detects a breach, making the factory's oversight tighten when things start going wrong.

The Tier-Max Connection

Risk-band routing works alongside the tier-max rule. The tier-max rule says a change spanning paths at different governance tiers inherits the strictest tier. Risk-band routing adds a second axis: even a change on a T0 path, mapped for full lights-out, will route to a human if the risk band is high. The two checks are independent. Both must pass for a change to advance autonomously. This is how the factory avoids single points of failure in its governance.

Why Three Bands

Three bands could become four, or five, or ten. The factory keeps it at three for a reason. Every additional band adds complexity to the routing logic and creates edge cases where changes fall between categories. Three bands give the factory enough granularity to differentiate routine changes from sensitive ones, without creating the kind of combinatorial complexity that makes governance hard to reason about. Low, medium, and high. That is all the resolution a good circuit breaker needs.

The Hard Rule

The code in risk_tier_gate is eleven lines. The critical one is: if verdict.risk is None or verdict.risk.band == "high", route to human. Eleven lines that guarantee no high-risk change ever slips through on a technicality. The factory does not deliberate. It checks a single field and acts. That is the whole point of putting governance in the core, where no LLM can touch it. Policy is code. The circuit breaker is automatic.