Release plan
What ordering costs you
The same twelve changes, sequenced three ways.
How this works, and what it can and cannot tell you
What blast radius means here
Every change carries a score built from four things: how visible it would be to a customer if it failed, how much of the daily transaction volume it touches, how long a silent failure would run before anyone noticed, and whether there is a clean way back. The first three add to the score. The fourth subtracts from it, because a change you can undo in ten minutes is not the same risk as one you cannot.
The weights are adjustable because they are judgments, not constants. A business that invoices monthly should weight detection lag heavily; one that ships same-day should weight visibility. Moving the sliders is the point — the ordering that survives several different weightings is the ordering worth arguing for.
Why sequencing by ease is the common failure
Ease and risk are independent. Rewriting a customer-facing document template is an hour's work and among the most visible things on the list; retiring a legacy integration is weeks of work that no customer will ever see. The instinct to start with whatever is quickest therefore has no relationship to starting with whatever is safest, and it routinely puts high-visibility changes into the first wave — before any verification has run at all.
Sequencing by blast radius inverts that. Contained changes go first, each verified while the system around it is still known-good, so that by the time a customer-visible change ships, the ground underneath it has already been checked.
Safest-first does not minimize every measure of risk
This is the part a model built to win an argument would leave out. Two measures matter here and they disagree.
Risk before the first gate is customer-visible work shipped before anything has been verified. Safest-first wins this decisively, and it is the measure that matches what actually goes wrong: a visible change landing on unchecked foundations.
Total unverified exposure accumulates how much altered ground sits beneath each visible change across the whole plan. On this measure ease-first often reads better, because shipping the risky work early means there is simply less underneath it. That is a real property, not a defect in the scoring.
So the honest claim is narrow: safest-first does not reduce total risk. It buys verified ground under every customer-visible change, and pays for that by deferring the visible wins. Whether that trade is worth making depends on what a failure costs you — which is a business judgment the model cannot make.
What a gate actually is
A gate is a check defined before the change ships, with a stated expected result and a named person who looks at it. It is not a status meeting and it is not waiting to see whether anyone complains. The distinction matters: a complaint is a detection method with a lag measured in days, and it arrives through the customer rather than through you.
Where this model is weakest
| Limitation | Why it matters |
|---|---|
| Scores are inputs, not measurements | Someone assigns visibility and reach by judgment. The model sequences those judgments consistently; it does not validate them. |
| Dependencies are not modeled | Real changes constrain each other — B may be impossible before A. A production version needs a dependency graph, and that graph can override the risk ordering outright. |
| Risk is treated as independent | Two low-score changes touching the same table can combine into something neither score predicts. The wave size limit is a blunt proxy for this. |
| No cost of delay | Sequencing safest-first defers benefit. If a change saves real money every week it waits, that pressure is real and this model does not price it. |
The data
The twelve changes are invented, and chosen to be recognizable in any business that runs orders through a system of record: master data, pricing, document generation, integrations, reporting. Nothing here is drawn from a real company's process inventory.