Prediction Drift
The output distribution moved. It is the earliest model-level signal, needs no labels, and is the one that catches train/serve skew on rollout day — because the model reacts to its inputs immediately and to the truth never.
The problem, the obvious approach, and why it breaks
Every lesson starts where the work starts: someone has a problem, and the first model that comes to mind looks fine offline.
The model's score distribution changed. What does that tell you on the day, before any outcome is known, and when is it the first thing you should look at?
A fraud team promoted a new model on Monday. The validation metrics were better. By Tuesday the manual-review queue, which the model feeds, is three times its normal size, and the analysts are asking whether fraud has suddenly tripled or something else has.
Quality is what matters, and quality needs labels. Wait for the chargebacks to arrive and evaluate the new model then. Until the labels are in there is nothing to measure.
The labels are ninety days out. The queue tripled on Tuesday. Waiting three months to learn whether Monday's rollout was a mistake is three months of analysts working a queue built by a possibly-broken model.
- The labels are ninety days out. The queue tripled on Tuesday. Waiting three months to learn whether Monday's rollout was a mistake is three months of analysts working a queue built by a possibly-broken model.
- The score distribution moved on rollout day because the serving path feeds the new model a feature the training path defined differently — train/serve skew. Nothing about that requires a label to detect; it required comparing the score distribution to the validation reference, on the day (Train / Serve Skew).
- The positive rate is a business quantity as well as a model one. A doubled queue is a cost regardless of whether the extra flags turn out to be fraud.
What is being predicted, and from what data
This domain leads with these two. A target nobody defined precisely is a label nobody can trust, and a dataset nobody can describe is a model nobody can debug.
- Predict chargeback within ninety days; the label arrives up to three months after the transaction. The decision is the review queue, driven by a threshold on the score.
- The queue size is a direct function of the score distribution above the threshold, so a change in the prediction distribution is a change in the business the same day.
- Scores per transaction from the prediction log, with the model version. A reference score distribution frozen from the validation set at promotion time.
- The features as served, in the same log, which is what makes prediction drift diagnosable rather than merely observable.
How it actually works
Precisely enough to predict its behaviour — not a framework API.
- The model is a deterministic function of its inputs, so its output distribution changes the moment its input distribution changes or its weights change. Prediction drift is the composite signal: it moves for feature drift, for a pipeline bug, for a new model version and for skew — for everything except concept drift, where inputs and weights are unchanged and only the truth moved (Concept Drift).
- On rollout day the useful comparison is the new model's serving score distribution against its own validation score distribution. If the model is receiving the inputs it was validated on, the two should match up to sampling noise. A mismatch on day one is skew or a broken feature, not the world, because the world did not change at deploy time.
- The positive rate — share of scores above the operating threshold — is the coarsest prediction-drift signal and the one that maps directly to the downstream workload. Mean, quantiles and a distance metric on the full distribution are finer.
Rollout day
The one moment when a prediction-distribution mismatch has an unambiguous reading is the first day of a rollout. The world did not change at deploy time. If the new model's serving scores do not match its validation scores, the model is not receiving the inputs it was validated on. That is skew or a broken feature, and it is detectable within the hour, not within the quarter.
The pipeline below is the promotion-to-rollout path with the comparison built in. The comparison is cheap; what it requires is that the validation score distribution was kept.
- 1Promote
Record the validation score distribution and positive rate at the operating threshold as the version's reference.
fails by Reference not stored; the only comparison later is against the old model, which is supposed to differ.
- 2Shadow
Serve the new model alongside the old without acting on its output; compare its serving score distribution to its reference.
fails by Shadow path uses batch features, so it reproduces the validation distribution and proves nothing about serving.
- 3Canary
Route a small share of traffic to the new model; compare positive rate to the reference and to the old model's, hourly.
fails by Canary share too small for the positive rate to have a usable interval; alerts on noise or on nothing.
- 4Full rollout
Route all traffic; keep the daily comparison against the reference for the life of the version.
fails by Reference refreshed to "last week" after a month, so the comparison walks with the drift.
None of these steps needs a label. The whole point is that the earliest model-level signal is available before any outcome exists, and the rollout design is what makes it readable.
The queue tripled
The fraud team's new model was validated on warehouse-computed features and served on stream-computed ones. One aggregate — spend in the last hour — is a calendar bucket in one and a rolling window in the other. The model reads a value from a distribution it never saw and flags a third of the traffic near the top of every hour. Validation said the model was better. Tuesday's positive rate said the serving inputs were wrong.
The gap between the offline number and the queue is the signature of skew, and prediction drift on rollout day is the instrument that catches it without waiting for a single chargeback.
Validation precision at the operating threshold improved on the new model; positive rate on the validation set was consistent with the old model's.
Serving positive rate three times the validation reference from the first hour; review queue tripled; analysts report the extra flags cluster just after the top of each hour.
- 1Train/serve skew on a windowed aggregate: the serving feature is from a different distribution than the validation feature, so the model's scores are from a distribution it was never validated on.
- 2The rollout compared the new model's positive rate to nothing — the validation reference was not stored — so the first reading anyone looked at was the queue.
- 3Fraud volume genuinely tripling was the alternative hypothesis, ruled out by the hour-of-day clustering, which is a pipeline signature and not a fraud one.
What prediction drift cannot see
A model's scores are a function of its inputs and its weights. When the inputs and the weights are unchanged, the scores are unchanged — whatever the world does. Concept drift is precisely that case: the relationship between inputs and outcome changes, the inputs do not, and the model produces the same distribution of confident scores that are now wrong. The prediction monitor stays green throughout.
So the assumption prediction drift checks is a narrow one, and its silence has to be read narrowly.
The serving score distribution for this version matches the validation score distribution, given correct inputs and the same threshold.
holds when Features arrive as trained, the artifact is the promoted one, and traffic mix is within the range the validation set covered.
breaks when A feature is skewed between training and serving; a pipeline bug replaces a feature with its default; the wrong artifact or preprocessing version is loaded; traffic mix shifts into a region the model scores differently.
respond On rollout day, hold or roll back and diff the features; in steady state, check the feature layer, then wait for the outcome slice — and remember that a stable reading rules out only what it measures.
1type Reference = { version: string; positiveRate: number; tolerance: number }2 3export function checkRollout(scores: number[], threshold: number, ref: Reference) {4 const positiveRate = scores.filter((s) => s >= threshold).length / scores.length5 const delta = positiveRate - ref.positiveRate6 // A mismatch on the first day is skew or a broken feature, not the world:7 // nothing about fraud changed at 09:00 on Monday.8 if (Math.abs(delta) > ref.tolerance) {9 return { ok: false, version: ref.version, positiveRate, expected: ref.positiveRate, action: 'hold rollout; diff serving features against the training path' }10 }11 return { ok: true, version: ref.version, positiveRate }12}The tolerance is the interesting parameter. It comes from the validation set's own variation by traffic mix and hour, recorded at promotion, not from a default.
How to build it
Most important first.
- Freeze the validation score distribution as the reference at promotion, and compare the serving distribution against it from the first hour of rollout (Canary Rollout, Shadow Deployment).
- Alert on positive rate against the reference, because it is the number the review team lives with, and on a distribution distance for the full score for the finer signal.
- When prediction drift fires, look at the feature monitors the same day: prediction drift with feature drift points at inputs; prediction drift with stable features on rollout day points at skew or the artifact (Feature Drift).
- Prediction drift with no feature drift and no rollout is the one case where the pointer is weak; it can be a legitimate shift in a feature the monitors do not cover, and the outcome data is what resolves it.
What to measure
Which number actually maps to the decision — and which numbers look relevant and are not.
- Positive rate at the operating threshold, hourly on rollout day and daily after, against the validation reference. This is the number that maps to the queue.
- Distance between the serving score distribution and the validation score distribution, per model version, so a rollout with two versions is not blended.
- Do not compare the new model's serving distribution to the old model's serving distribution and call a difference drift; the models are supposed to differ. Compare each to its own validation reference.
What must stay true after deployment
The field this whole domain exists for. A model is a set of assumptions with weights attached; these are the ones a monitor or a test should be checking.
- The serving score distribution for a model version matches that version's validation score distribution, up to sampling noise and known traffic-mix variation, when inputs are correct.
- The reference is per version and refreshed at promotion, so a comparison is always of a model against its own validation.
- The positive rate maps to the downstream workload — the threshold in serving is the threshold the reference was computed at.
- Offline: at promotion, record the validation score distribution and positive rate at the operating threshold, and the expected variation by traffic mix.
- Online: on rollout day, compare hourly; a shadow or canary period makes the comparison possible before the new model feeds the queue.
- Over time: daily distribution distance per version; when it moves, check the feature layer the same day and the outcome layer when labels arrive.
What can go wrong
- The validation reference was computed on warehouse features and the serving distribution on serving features; the mismatch is the skew being measured, and it is read as "the new model scores differently", which is expected and dismissed.
- Traffic mix changes by hour — fraud is more common at night — and an hourly positive-rate alert against a daily reference fires every evening until it is muted.
- The prediction distribution is stable and quality is falling; the team reads the stability as health and misses concept drift for the whole label delay.
- A per-version reference requires the promotion pipeline to emit it, and a comparison that accounts for traffic mix requires knowing the mix.
- Alerting on positive rate means alerting on legitimate changes in fraud volume; the response has to include "check whether the world changed" and not only "check the model".
- A shadow deployment to observe the score distribution before it drives decisions is a second serving path to run and pay for.
- "The score distribution changed, so the model is worse." It changed. Whether it is worse needs the outcomes; whether the inputs are right needs the feature layer. The distribution alone says "something moved".
- "The prediction distribution is stable, so nothing is wrong." Concept drift leaves the prediction distribution exactly where it was. Stability rules out a class of problems, not all of them.
- "If offline AUC improved, ship it." The new model's better validation number was computed on inputs the serving path did not reproduce. Prediction drift on rollout day is how you find that out before the labels do.
Where this applies
ML advice is stated as universal far more often than it is. These labels say what each claim is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThat the output distribution responds immediately to inputs and weights and never to the truth holds for every deterministic model; for a ranker the equivalent signal is the distribution of top-k scores or of positions, not a single positive rate.
- TASK-SPECIFICFor a classifier the positive rate at the threshold maps straight to a workload; for a regressor the mean and spread of predictions are the signals and there is no single threshold to anchor them, so the reference has to be the whole distribution.
- SIMULATEDThe prediction-mean readings and the same-day movement in the feature-bug scenario are from the Drift Explorer's synthetic model; the alert constant of a 0.1 shift in prediction mean is the explorer's, for the shape of the argument.
Where the depth lives
This domain teaches the model and hands the rest off by name.