Rollback and Model Kill Criteria
Deciding, before a model goes live, exactly what evidence will trigger pulling it back to the previous version — so the decision is made calmly in advance rather than argued over while losses are mounting.
Prerequisites: Canary Releases for Models
Every live model eventually does something worse than expected — a data feed hiccups, a regime shifts, a bug slips past testing. The question isn't whether that will happen but whether the response is decided calmly ahead of time or improvised under pressure while money is being lost. Kill criteria are the pre-committed, numeric answer to "at what point do we pull this model back to the last known-good version, no discussion needed?"
Writing criteria that actually trigger
A good kill criterion is specific, measurable, and checkable automatically — not "if it seems to be performing badly," but a concrete rule like "if realized P&L over any rolling 2-hour window falls below −$50,000" or "if the prediction distribution's population stability index versus the training distribution exceeds 0.25" or "if inference latency's 99th percentile exceeds 3 milliseconds for more than 60 consecutive seconds." Criteria typically combine three categories: performance (the thing the model is meant to achieve going visibly wrong), distributional (the live input or output distribution drifting far from what the model was built and validated on), and operational (latency, error rate, or infrastructure health breaching a hard limit regardless of whether the model's decisions look reasonable).
Once triggered, a rollback should be a scripted, tested action — flipping traffic back to the previous model version — not a manual scramble to figure out how, which is why the rollback mechanism itself needs to be exercised in advance, the same way a fire drill is run before an actual fire.
Worked example
Before deploying a new volatility-forecasting model that feeds an options desk's hedging decisions, the team writes three kill criteria: rolling 4-hour realized hedging cost exceeding the prior model's worst historical 4-hour window by more than 40%, forecast-versus-realized-vol tracking error's rolling 1-day RMSE exceeding 1.5× the validation-period RMSE, and any single forecast falling outside a hard sanity bound of 5% to 200% annualized vol. Three weeks after launch, an exchange feed outage causes a burst of stale quotes, and the model's tracking-error criterion trips at 2.1× the validation RMSE within eleven minutes. The pre-scripted rollback executes automatically, reverting to the previous model, and the desk investigates the feed issue with the position already de-risked rather than debating in real time whether the elevated error was "just noise."
What this means in practice
Kill criteria should be written and agreed with the same people who would otherwise resist the rollback in the moment — the desk that wants to give the model "one more hour" to prove itself. Writing the numbers down beforehand, with sign-off from all stakeholders, removes exactly that argument when it matters most: the criteria were agreed to when no one had an emotional stake in a particular answer.
Kill criteria are specific, automatically checkable thresholds — on performance, distributional drift, and operational health — agreed before a model goes live, so a rollback decision is executed mechanically rather than debated under pressure while the model is actively losing money.
The most common failure isn't missing kill criteria — it's having them on paper but not wiring them to an automatic trigger, so a human still has to notice the breach, escalate it, and get permission to act, by which point the criteria have failed to do their one job: acting fast.
Related concepts
Practice in interviews
Further reading
- Sculley et al., Hidden Technical Debt in Machine Learning Systems, 2015