Model quality tells you whether an AI feature can work. It tells you almost nothing about whether you will find out when it stops working. Those are different questions, and only the second one decides whether a release candidate should go out this week.
Most readiness conversations still collapse into one number — accuracy, or F1, or a win rate against the previous model on a held-out set. The number passes, the demo behaves, and everything else gets filed as post-launch work. We see this pattern regularly, and the failure it produces is not a bad model. It is a good model that degrades quietly for three weeks because nobody agreed what “degraded” looks like, who gets paged, or how the previous version comes back.
Four signals decide readiness, and all four exist independently of model quality: a drift posture, a rehearsed rollback path, named on-call ownership for AI-specific failure modes, and an eval-evidence pack a reviewer can audit without re-running the notebook.
What actually decides whether an AI feature is ready to ship?
Each signal answers a distinct operational question, and each has a pass condition that is checkable rather than assertable. The table below is the rubric we score a release candidate against.
| Signal | Question it answers | Pass condition | Common failure |
|---|---|---|---|
| Drift posture | Will we notice when input or output distributions move? | A recorded pre-rollout baseline, a numeric threshold per monitored signal, and a named recipient of the alert | Dashboards exist; no threshold, no recipient |
| Rollback path | Can the previous version come back, and how fast? | A rollback executed at least once against the release candidate, with the elapsed time recorded | A runbook page nobody has run |
| On-call ownership | Who responds when the failure is model-shaped, not service-shaped? | An ownership matrix naming a person per AI-specific failure mode, acknowledged by that person | The platform rota inherits it by default |
| Eval-evidence pack | Can a reviewer approve without trusting a verbal claim? | Dated, versioned artefacts tied to the exact candidate, readable without executing code | A slide with one headline metric |
The signals are ordered by how often they are missing, not by importance. A missing drift posture is the most common gap; a missing rollback rehearsal is the most expensive one.
Drift posture: baseline, threshold, recipient
A drift posture is not “we have monitoring”. It is three concrete artefacts. The baseline is a snapshot of the input feature distributions and output score distribution captured before rollout, against the candidate itself — a baseline taken from the outgoing model is measuring the wrong thing. The threshold is a number that fires: a population stability index above some agreed value, a shift in the positive-prediction rate beyond a stated band, a rise in null or out-of-vocabulary rates. The recipient is a human name attached to each firing threshold.
The minimum viable set for a first release is small: input distribution on the top few features by importance, output score distribution, prediction volume, and upstream data freshness. Teams tend to over-scope this and then ship none of it. Four monitored signals with real thresholds beat twenty logged metrics with none.
Why a rehearsed rollback counts and a documented one does not
Documented rollback paths fail for boring reasons that only surface under execution: the previous model artefact was garbage-collected from the registry, the feature store schema moved forward and the old model’s inputs no longer resolve, a cached embedding index is version-coupled to the new model, or the rollback requires a deploy that itself takes forty minutes. None of these appear in a runbook. All of them appear the first time someone runs it.
Rehearsal converts an estimate into a measurement. Time-to-rollback measured from a rehearsal is a benchmark-class number for that specific release candidate; time-to-rollback as written in a wiki is a guess. In our experience, the first rehearsal on a system that has never done one takes several multiples of the estimated time, and the gap is almost always a dependency nobody had modelled — most often a stateful artefact like an index or a cache that does not roll back with the weights.
Ownership has to name the model-shaped failures
The classical on-call rota covers latency, error rate, and saturation. AI features fail in ways that never trip those. The ownership matrix has to name the failure mode explicitly and attach a person to it:
- Silent quality degradation with no error-rate change
- Input drift from an upstream data pipeline change
- Training-serving skew after a feature-engineering edit
- A dependency on a hosted model whose behaviour changes without a version bump
- Fairness or segment-level regression that averages out in the aggregate metric
The test is not whether the matrix exists. It is whether the named person has acknowledged the row and knows what the first response action is. An unacknowledged matrix is documentation, not ownership.
The eval-evidence pack is an audit surface
The pack’s job is to let a reviewer form a verdict without re-running the training or eval code. That means dated, versioned artefacts bound to the exact release candidate: eval results with coverage stated per slice rather than in aggregate, the data snapshot identifier, the comparison baseline, and the config that produced the run. Our sibling article on what a release-readiness evidence pack contains goes into the artefact inventory in detail; the point here is only that its absence is a scoreable gap, not a formatting complaint.
Tooling makes this cheap. MLflow or a comparable tracking layer, plus a pinned dataset version and a serialised eval config, gets most teams to an auditable pack without new infrastructure. The [production-AI monitoring and validation harness](Production AI Monitoring Harness) we build with clients produces the evidence for each of the four signals against a buyer’s actual release candidate, which is a different exercise from generating it against a reference workload.
Hold, or accepted risk?
A missing signal does not automatically stop a release. It forces a decision, and the decision gets recorded. That distinction is what keeps a gate from decaying into either theatre or obstruction.
Hard hold — the release does not ship:
- No rollback path has been executed against this candidate
- No named, acknowledged owner for the primary failure mode
- No pre-rollout drift baseline recorded (you cannot retrofit a baseline after traffic starts)
Accepted risk — ships with a named owner and an expiry date:
- Drift thresholds set on a subset of the intended signals
- Eval coverage thin on a low-volume segment, with the segment named
- Rollback rehearsed on staging but not on production topology, with a rehearsal scheduled
The expiry date is the load-bearing part. An accepted risk without one is a permanent gap wearing a temporary label. We ask for a date and an owner on the same line as the acceptance, in the release record, so the next gate reads the previous gate’s debt.
Re-scoring when only the model changes
The most common question after the first gate is how much of this repeats when the weights change but the surrounding system does not. Not all of it. The rollback rehearsal and the ownership matrix are properties of the system, so they carry forward until the deployment topology or the team changes. The drift baseline and the eval-evidence pack are properties of the candidate, so both are re-produced every time: a new model has a new output distribution, which means the old baseline would page on the change itself rather than on degradation.
That asymmetry is what makes the rubric cheap to run repeatedly. Two signals are amortised infrastructure; two are per-release artefacts. Teams that build the harness once find the recurring cost lands mostly in regenerating the evidence pack, which is automatable.
The rubric only produces value when the verdict is written down. A recorded verdict per release gives you a per-version baseline for comparing incident rates, a defensible answer when a hold is questioned, and a traceable one when a ship decision turns out to have been wrong. We develop the surrounding release framework — how the gate fits into deployment staging, versioning, and the ownership model — in our work on AI infrastructure and SaaS platform reliability, which is where the four signals get instrumented rather than merely scored.
Which of the four is missing on your next release candidate — and if you already know the answer, why has it survived the last three releases?
Frequently Asked Questions
What does “When is an AI feature ready to ship to production?” mean in practice — which signals actually decide it? Readiness is decided by four operational signals rather than by model quality: a drift posture with a recorded baseline and firing thresholds, a rollback path someone has actually executed, an ownership matrix naming a person per AI-specific failure mode, and an eval-evidence pack a reviewer can audit without running code. Model metrics tell you the feature can work; these four tell you whether you will detect and reverse it when it stops working.
What is a drift posture, and what is the minimum baseline and threshold set a release needs before it ships? A drift posture is a pre-rollout baseline of input and output distributions captured against the candidate itself, a numeric threshold per monitored signal, and a named human recipient for each alert. The minimum practical set is input distribution on the highest-importance features, output score distribution, prediction volume, and upstream data freshness. Four monitored signals with real thresholds are worth more than twenty logged metrics with none.
Why does a rehearsed rollback path count as a readiness signal when a documented one does not? Documented rollbacks fail on dependencies that only surface under execution — a garbage-collected artefact, a forward-migrated feature schema, a version-coupled embedding index, or a deploy that itself takes far longer than assumed. Rehearsal converts an estimated time-to-rollback into a measured one for that specific candidate. A runbook nobody has run is an assertion, not evidence.
Who owns an AI feature on-call, and what AI-specific failure modes must the ownership matrix name? The matrix must name an acknowledged individual for each model-shaped failure mode that the classical latency/error/saturation rota does not cover: silent quality degradation without error-rate change, upstream input drift, training-serving skew, hosted-model behaviour change without a version bump, and segment-level regression hidden by aggregate metrics. Acknowledgement matters — an unacknowledged matrix is documentation rather than ownership.
What belongs in an eval-evidence pack so a reviewer can approve without re-running the training or eval code? Dated, versioned artefacts bound to the exact release candidate: eval results with coverage stated per slice rather than in aggregate, the data snapshot identifier, the comparison baseline, and the config that produced the run. The test is whether a reviewer can form a verdict from the artefacts alone. A tracking layer plus a pinned dataset version usually gets a team there without new infrastructure.
When is a missing signal a hard hold versus an accepted risk with a named owner and an expiry date? A missing signal is a hard hold when it cannot be retrofitted after traffic starts or when its absence removes the ability to respond at all — no executed rollback against this candidate, no acknowledged owner for the primary failure mode, no pre-rollout drift baseline. Partial coverage of thresholds, thin eval coverage on a named low-volume segment, or a staging-only rehearsal can ship as accepted risk. The acceptance is only real if it carries an owner and a date on the same line in the release record.
How do the four signals get re-scored when only the model version changes and the surrounding system does not? The rollback rehearsal and the ownership matrix are system properties and carry forward until topology or team changes. The drift baseline and the eval-evidence pack are candidate properties and must be regenerated every time, because a new model produces a new output distribution that would otherwise page on the change itself. That split is why the rubric is cheap to run repeatedly — two signals are amortised, two are per-release.
Three checkpoints before you deploy
Ship when your monitoring catches failure modes faster than users report them, your rollback procedure has been tested under load, and the team can articulate exactly which accuracy threshold justifies pulling the feature offline.
