What changes when an ML model touches the field

September 2026 · 3 min read

In the lab, a model is finished when the metrics look good. In the field, that's the day it starts falling apart.

Not because the model changes. Because everything around it does. A sensor drifts out of calibration and nobody tells your feature pipeline. A machine gets an overhaul, and its "normal" moves somewhere your training data has never been. An operator changes a setpoint because summer arrived. Your model keeps scoring away, perfectly confident, increasingly wrong.

The lab question is "is the model right?" The field question is different: "is the model still talking about the same machine?"

A deployed model is not an artifact. It's a relationship between a piece of math and a physical world that never stops moving.

Here's what nobody puts in the paper: in the field, the data is not a given. It's produced — by sensors that fail, networks that drop packets, technicians who mount an accelerometer two bolts to the left of where the last one sat. Half of "model maintenance" is really instrumentation maintenance wearing a software costume.

And the humans adapt around your model faster than you can retrain it. If it's useful, they lean on it and stop looking at the raw signals — so its blind spots become the whole team's blind spots. If it's annoying, they route around it, and you find out a year later that your alerts have been going to a folder.

So the deliverable was never the model. It's the system that notices when the model and the world drift apart: input monitoring that catches the dead sensor before the model interprets silence as health. A retraining trigger owned by a person, not a cron job. And a habit of asking, every few months, the only question that matters — if this model quietly went wrong tomorrow, how would we know?

A good model with no answer to that question is a bad maintenance system. It just hasn't proven it yet.