The assumption that breaks every deployment
Most ML systems are built on an implicit assumption: that the world the model was trained on will continue to resemble the world it is deployed into.
It will not. Roughly 91% of ML models degrade over time, and the root cause is almost always a data mismatch. The model has not changed. Everything around it has.
What makes this expensive is not the decay itself — decay is predictable and manageable. It is that most organisations discover it reactively, weeks after it began, through a business metric rather than a system alert. By the time a revenue number moves, the model has been quietly wrong for a month.
Three clocks that fall out of sync
Production ML runs on three clocks that often fall out of sync. User behaviour changes on one clock. Labels arrive on another. Deployment and approval cycles move on a third. When those clocks drift apart, the model starts learning from a world that has already expired.
This framing is more useful than the usual one, because it explains failures that look like drift but are not.
A team may retrain daily and still serve stale features. A feature pipeline may stay fresh while labels lag long enough to poison feedback loops. An inference service may promote a candidate that passed offline checks but fails on live traffic slices because the request mix changed between evaluation and release.
Each of those failures looks like model drift on the surface. In practice, each one starts as a coordination failure inside the pipeline.
The implication for engineering leaders is direct: the pipeline is the adaptive asset and the model is one component inside it. Budget and attention should favour observability, feedback plumbing, and release control before another round of model tuning.
Why periodic checking is not a feedback loop
There is a meaningful difference between checking on a model and operating a feedback loop.
Periodic checking is a scheduled review — someone opens a dashboard monthly, looks at aggregate accuracy, and decides whether to act. It fails for three reasons.
Aggregate metrics hide slice failures. A model at 94% overall can be at 61% on a segment representing 4% of volume — usually the rare, high-consequence segment the system exists to catch. Monthly review of a single number will never surface this.
Detection lags the cause by weeks. By the time enough labeled outcomes have accumulated to move an accuracy metric, the underlying distribution shift may be two months old and several thousand bad predictions deep.
Human review does not scale with model count. An organisation with five models can review them manually. An organisation with fifty cannot, and manual drift management becomes unsustainable as model inventories grow.
A continuous feedback loop instead runs as infrastructure: predictions are ingested as they occur, drift is computed on a fixed cadence, slices are decomposed automatically, and thresholds trigger action without waiting for someone to notice.
Detecting before ground truth arrives
One practical technique deserves specific mention, because it changes the economics of monitoring.
Do not wait for labeled data to detect model degradation. Proxy metrics like prediction distribution shift and feature drift can surface problems days or weeks before you have enough labeled feedback to measure accuracy directly.
In most production settings, ground truth is delayed. A fraud prediction may not be confirmed for thirty days. A defect classification may not be verified until a downstream inspection. If your only degradation signal requires labels, you are structurally blind for the length of your label delay.
Input drift and prediction drift require no labels at all. They are computed entirely from what the model receives and what it emits. They are weaker signals — drift without evaluation impact is a false alarm and burns on-call attention — but they are early, and combining them with accuracy once labels arrive gives you both timeliness and confidence.
The correct posture is a tiered response: automate remediation on small drifts, human review for moderate ones, emergency intervention for severe shifts.
The trap inside feedback loops
Feedback loops have a specific failure mode worth naming, because it is subtle and self-reinforcing.
Feedback loops occur when a model's predictions influence the data it will be trained on in the next cycle. A recommendation model that only shows popular items will generate training data that reinforces that bias.
The same dynamic applies anywhere the model's output shapes what data gets collected or reviewed. If low-confidence predictions are routed for human review and high-confidence ones are not, the corrected data over-represents cases the model already found hard — useful for targeted improvement, but skewed if used naively for full retraining.
The mitigation is deliberate composition control: track what proportion of a retraining set came from correction cycles versus fresh sampling, and maintain explicit coverage of cases the model currently handles well. Correction data improves weak slices. It should not be allowed to silently become the entire dataset.
What a complete loop contains
Six components, and the loop is only as strong as the weakest.