Drift is quiet. By the time you notice it, the damage is already done.

Data drift and concept drift can silently reduce model reliability after deployment. Drift detection and evidence-led retraining triggers are what keep the AI capability useful as the operating world changes around it.

Across the eleven articles that preceded this one, we have argued that industrial AI succeeds or fails not at the moment of deployment but in the discipline that surrounds it. Data has to be ready. Signals have to be engineered. Features have to hold from training to serving. Models have to be reproducible. Pre-production validation has to be real. Deployment has to be governed. And the system has to be monitored after go-live. Each of those arguments is necessary. None of them is sufficient on its own. The discipline that ties the closing stage together, and that closes Round 1 of this series, is the recognition that the world the model was trained against does not stay still.

In our experience working with mining and industrial organisations, models almost never fail loudly in production. They drift. They continue to produce predictions on data that no longer looks like the data they learned from, or in operating conditions where the relationship between inputs and outcomes has quietly shifted. The model is technically running. The dashboards are populated. The alerts are flowing. And the outputs are becoming less reliable, less actionable, and less trusted, week by week.

This is drift. It is the most common reason production AI loses reliability over time, and it is the discipline that completes the Stage 06 conversation.

Data drift and concept drift are different problems

Both reduce model reliability. Each requires a different response.

Two distinct phenomena sit underneath the term drift. They are often discussed interchangeably. In practice, they require different monitoring signals and different operational responses, so the distinction is worth getting right.

Data drift is the more visible of the two. It surfaces in monitoring dashboards through changes in distributions, ranges, or missing-value rates. Concept drift is harder to detect because the input data may still look entirely normal. The conditions the data represents have shifted, but the sensors continue to report values within their expected ranges. In our experience, concept drift is the more dangerous of the two precisely because it can persist for longer before anyone notices.

Data drift means the inputs have changed. Concept drift means the world the inputs describe has changed. The first is visible. The second often is not.

What data drift looks like in mining operations

The model is still running. The inputs no longer look like the training data.

Data drift in a mining environment arrives gradually, and from many directions at once. The patterns we have seen most often include:

• Ore characteristics change. The mineralogical profile feeding the plant shifts as the ore body is worked through. Hardness, grade, and composition move outside the operating envelope the training data represented.

• Equipment ages. Wear patterns on a SAG mill or crusher evolve. Vibration signatures, power draw distributions, and bearing temperature ranges drift as the asset accumulates operating hours.

• Sensors change. An instrument is replaced or recalibrated. The new sensor reports the same physical parameter, but with subtly different distribution characteristics.

• Operating throughput changes. The plant runs harder, slower, or differently than it did during the training period. The same feature values now describe different operational reality.

• Asset load profiles change. A pump or conveyor operates under different duty cycles. Power, flow, and temperature distributions shift accordingly.

• Fleet utilisation changes. Haul truck operating patterns shift with mine plan changes, weather seasons, or operational restructuring.

• Data pipeline changes. A historian tag is renamed, a feature transformation is modified, or an integration point is upgraded, and the values reaching the model are no longer constructed exactly as they were before.

Each of these is a normal part of operating a working mine. None of them is a fault of the AI system. All of them produce data drift, and all of them require monitoring discipline to detect before they affect the model's operational usefulness.

What concept drift looks like in mining operations

The inputs may still look normal. The pattern no longer means what it used to.

Concept drift is harder to recognise because the symptoms do not appear in the input data. The data continues to look as expected. The model continues to score within its trained range. What has changed is the underlying relationship the model was built to detect. In an industrial AI context, the patterns we have seen include:

• A maintenance programme change alters the failure pattern. A new preventive intervention regime catches degradation earlier, changing what the lead-up signature to failure looks like.

• A new operating procedure changes equipment behaviour before failure. Operators are now responding to certain conditions differently than the training data reflected.

• A repaired asset no longer degrades the same way. After a major overhaul, the same component class behaves differently from the unit the model learned from.

• A new ore blend changes process relationships. The relationship between power draw, throughput, and mill performance now differs from what the historical data captured.

• A control strategy change shifts process behaviour. DCS logic is updated, and the process now responds to disturbances differently than before.

• Operator response to alerts evolves. Over time, the maintenance team begins to act on the model's alerts faster, slower, or differently, and the operational outcomes the model is associated with shift accordingly.

Concept drift is detected, in practice, not by looking at the inputs but by looking at the model's relationship to the operational outcome it was deployed to support. Predictions look normal. Operators report that the alerts are less useful. False-positive rates climb. Lead times shorten. Trust erodes. None of this would surface from input distribution monitoring alone, which is exactly why business outcome monitoring matters as much as technical monitoring.

What drift detection should monitor

Signals across inputs, features, predictions, and outcomes

Data drift detection ML practice in industrial AI requires monitoring across multiple dimensions, because no single signal catches all forms of drift. In practical terms, the monitoring layer should track the following:

• Input distributions and ranges. Has the distribution of each model input shifted significantly from its baseline?

• Feature distributions. Have engineered features begun to behave differently, even if the raw inputs look similar?

• Missing-value rates and data freshness. Are inputs arriving as completely and as promptly as they did during training?

• Prediction distributions. Has the shape, mean, or variance of model output changed in ways that suggest the model is encountering conditions outside its training envelope?

• Alert frequency and concentration. Is the model generating more or fewer alerts than its operational baseline, and are alerts clustering on specific assets, shifts, or sites?

• Confidence scores. Is model confidence dropping systematically, suggesting the model is unsure of its own outputs?

• False-positive and false-negative signals. Where operational feedback is available, are these rates consistent with what was expected at deployment?

• Business outcome changes. Is the model still associated with the operational improvement it was deployed to deliver?

• Operator feedback signals. Are maintenance and operations teams reporting that the model output is less useful, more confusing, or less actionable than it once was?

• Performance decomposed by segment. Is the model performing consistently across asset class, shift, site, and operating mode, or has performance degraded in a specific subset?

None of these signals alone is sufficient. Together, they constitute the monitoring fabric that allows drift to be detected while it is still being managed rather than after operational trust has been lost.

Model retraining triggers should be evidence-led

Retraining on a calendar is rarely the right answer

Model retraining triggers enterprise discipline is the practice of deciding when to retrain a deployed model based on operational and statistical evidence, rather than on a fixed schedule or on a reactive response to a visible failure. In our experience, both extremes produce poor outcomes. Calendar-based retraining is wasteful when nothing has changed, and dangerous when something has changed long before the calendar requires action. Reactive retraining after a visible failure is, by definition, too late.

Effective retraining triggers in enterprise AI include the following:

• Sustained data distribution change. A meaningful and durable shift in input or feature distributions that exceeds the agreed monitoring threshold.

• Predictions drift over time. A pattern of model output shifting in ways that cannot be explained by current operating conditions.

• Increase in false positives or missed events. Operational feedback or labelled outcome data showing the model is no longer performing within tolerance.

• Drop in business outcome performance. The operational improvement the model was deployed to deliver is no longer being achieved.

• Introduction of a new asset class, site, or operating mode. The model is being asked to generalise to conditions it has no training evidence for.

• Maintenance strategy change. An operational policy change that affects the underlying failure pattern the model is built to detect.

• Sensor or pipeline change. Hardware or upstream system changes that alter the data the model receives.

• Operator feedback indicating reduced trust. A qualitative signal that, in industrial AI, often precedes the quantitative one.

When any of these triggers fires, the response is not automatic retraining. It is a structured decision: investigate the cause, confirm that retraining (rather than a pipeline fix or feature update) is the right response, retrain against current data, validate the retrained model through the same Stage 04 discipline applied to the original, and redeploy under the same Stage 05 release controls. Retraining is itself a Stage 03 activity. Without that rigour, the cure becomes its own source of operational risk.

Retraining should be triggered by evidence, not by panic. And when it is triggered, it has to go through the same discipline as the original model build.

The leadership mistake we see repeatedly

Asking 'when should we retrain?' instead of 'what tells us the model no longer reflects reality?'

The most common leadership question about deployed models is, when should we retrain? The implicit assumption is that retraining is a calendar-driven maintenance activity. In our experience, that assumption produces both wasted effort and missed risk in roughly equal measure. The better question reframes the entire conversation.

What evidence will tell us that the model no longer reflects operating reality? If the team can answer that question with specific reference to monitoring signals, agreed thresholds, and decision criteria, the AI capability is being governed as an operating system. If the team cannot answer it, retraining decisions are being made by guesswork, and the model is being trusted further than the evidence supports.

Closing Round 1: the six-stage AI Productionization Value Chain

From data readiness to model health, the full operating system

Week 12 closes the first round of this series. Over twelve articles, we have walked through the full CoffeeBeans AI Productionization Value Chain in a mining context, from the foundations of data readiness to the discipline of model health and drift management. The argument across the series is structural: industrial AI does not succeed because of strong algorithms. It succeeds because the system around the algorithm is built to hold.

Productionising AI in an industrial environment is not a straight line from data to model. It is a managed operating system, designed to keep the AI capability useful even as the operating world it serves continues to change. Each of the six stages is necessary. Stage 06, where this round ends, is what closes the loop and turns the previous five stages into a capability that sustains itself.

Productionising AI is not a project. It is the operating discipline that keeps the system useful after the world changes around it.

How CoffeeBeans helps

Bringing drift discipline to industrial AI programmes

CoffeeBeans works with mining and industrial organisations to build the data drift detection ML infrastructure that turns deployed AI from a one-time delivery into a sustained operational capability. Our Stage 06 engagements typically begin with the design of the drift monitoring layer: which input and feature distributions matter for each model, where concept drift industrial AI signals are most likely to emerge, what thresholds make sense for the specific operational tempo of the plant, and how monitoring outputs route to data science, reliability, and operations teams.

From there, we operationalise the discipline. Model retraining triggers enterprise criteria that are agreed in advance with the operational stakeholders who will live with the consequences. Retraining workflows are designed to follow the same Stage 03 experimentation rigour, Stage 04 validation, and Stage 05 deployment governance that the original model build received. The objective is straightforward: when an industrial AI capability is live, the organisation should know quickly when reality has moved away from what the model assumed, and should retrain on evidence rather than on calendar.

Is your model still right about a world that has moved?

If your industrial AI programme has deployed models that perform well at first but quietly lose accuracy or trust over time, drift is almost always the underlying cause. CoffeeBeans can help your team design the data drift detection ML monitoring layer, configure concept drift industrial AI signals for your operational context, and embed the model retraining triggers enterprise discipline that production AI needs to sustain itself. Talk to our Enterprise AI practice about drift and retraining in your operation.