Before a staged rollout starts, what stopping rule and blast-radius limit must already be defined?

### Deploy is not release A staged rollout separates *deployed* from *exposed*. The new version is running, and a control - a flag, a routing rule, a cohort list - decides who reaches it. That separation is the precondition for everything else: if exposure cannot be changed without a deployment, there is no rollout, only a series of releases, and the response to bad news is measured in build minutes rather than seconds. ### The stopping rule, written before the ramp The reason to predeclare is human, not statistical. Once a change is at 40 percent and the team has spent three weeks on it, every ambiguous signal acquires a benign explanation. A stopping rule written before anyone is invested is the only version of the rule that is honest. It needs five parts. **Conditions, not adjectives.** *If it looks bad, we stop* is not a rule. *Any violation of the gross-equals-net-plus-deductions invariant, at all*; *preview p99 latency above 1.4 times the pre-ramp baseline sustained for 25 minutes*; *any manual correction raised against a payslip produced by the new version* - those are rules. Note the mixed shapes: money invariants are zero-tolerance counts, performance is a sustained relative comparison. **An observation window per stage.** The window must be at least as long as the slowest criterion takes to report. If the correction-rate signal for a payroll defect only becomes readable after a pay cycle completes, a stage that advances in two hours has observed nothing but latency. Teams that ramp to 100 percent inside a day and then discover the defect at month-end did have a stopping rule; they just never gave it time to fire. **A named decider.** Either an automated policy that halts and reverts on its own, or a specific role that owns the call. *The team will decide* means nobody decides at three in the morning. **A default for ambiguity.** The most valuable clause in the rule, because ambiguity is the common case. Ambiguous means roll back, investigate off the critical path, and ramp again. The alternative - hold and keep watching - is how a rollout stalls at 11 percent for a month, leaving two versions in production, two data shapes and doubled support load. **An expiry.** A stage that has not advanced or reverted within a set time reverts automatically. Without this, the rollout quietly becomes a permanent fork. ### Blast radius is about consequence, not percentage The most common mistake is to equate blast radius with the exposure share. Four dimensions actually bound it. **Who.** Cohort ordering from lowest to highest consequence: internal staff first, then a small low-risk customer segment, then general population. Never the largest payroll customer first, and be aware that a random percentage draws from every segment at once - random exposure is fine for a preview screen and reckless for a pay-run submission. **What data.** A version that writes a new field the old version cannot read has extended its blast radius into the data, and reverting the code no longer reverts the state. The safe shape is to make the schema change first, tolerated by both versions, and only then ramp the behaviour. **Which side effects are irreversible.** This dominates everything. A payment instruction sent, a filing submitted, a notification emailed to fourteen thousand employees - none of these can be rolled back. A version at 2 percent exposure that can disburse money has an effectively unbounded radius, and the mitigation is a hold-and-review gate on the irreversible step, not a smaller percentage. **For how long.** Exposure multiplied by duration is what determines how many records were affected before the rule fired. A short window at a small share is genuinely bounded; the same share running for a three-week release train is not. ### Preconditions that let a rollout be read at all Even a perfect rule is unusable without three things in place first. **Attribution**: every record and every telemetry event carries the version that produced it, or you can see a metric move without knowing which of the train's many changes moved it. **A verified revert path**: exercised before the ramp, with a measured time-to-revert - if reverting takes 40 minutes, your stopping rule is really *40 minutes of damage after the criterion fires*. **A pre-ramp baseline**: the same measurements taken before exposure, since every criterion here is comparative. ### A concrete shape For a gross-to-net rewrite on a three-week release train: stages at 2, 11, 40 and 100 percent; cohort order internal staff, then employers under 50 employees, then all; observation per stage of one complete pay cycle for anything touching money; abort on any money-invariant violation, on sustained p99 latency above 1.4 times baseline for 25 minutes, or on the kill switch; revert by routing to the previous version within 90 seconds with no deployment; automatic revert if a stage has not advanced within the train's three weeks. ### Where this stops The rollout decision described here is deliberately coarse: is this version harmful, yes or no. Deciding whether a metric difference between exposed and unexposed groups is real - randomisation unit, how much data is needed, the penalty for repeated looks - is experiment design, a different discipline with its own machinery. Conflating the two produces bad releases and bad measurements alike: a safety call delayed for statistical certainty, or a business result claimed from a ramp never designed to measure one.