Manufacturing

Predictive maintenance.
Alerts you act on.

Predictive maintenance fails on the floor far more often than in the model. Maintenance teams have been trained by a decade of false alarms to ignore automated warnings, and a new system inherits that scepticism on day one.

THE DATA PROBLEM COMES FIRST

Predicting failure requires examples of failure, labelled with what failed and when. Most plants have abundant sensor history and poor failure labelling: the maintenance record says “bearing replaced” with a date that is the date of the work order, not the date of the failure, and often not the date the machine actually started degrading.

Reconciling maintenance records against sensor history to produce usable labels is typically the largest single task in these projects, and it is where a language model contributes most — reading free-text work orders, technician notes and shift logs, and aligning them to equipment and time. That is unglamorous, and it is the step that determines whether anything downstream is possible.

The second constraint is that critical equipment fails rarely, by design. A machine with three failures in five years does not support a model that learns failure signatures. In those cases the honest answer is anomaly detection against normal operation plus physics-informed thresholds, not a supervised model pretending to predict from three examples.

DESIGNING AGAINST ALARM FATIGUE

Predict a window, not a moment

“Elevated failure probability in the next two to six weeks” fits how maintenance is actually scheduled. A precise date is both less achievable and less useful, and being visibly wrong about it destroys trust quickly.

Say what the evidence is

Which sensors, what pattern, how it compares to previous failures on this asset class. A technician who can evaluate the reasoning will investigate; one handed a bare score will not, and is right not to.

Rank against capacity

A maintenance team can act on a limited number of interventions per week. Surface that many, ranked by expected cost avoided, rather than every asset above a threshold — a list longer than the team's capacity is a list that gets ignored entirely.

Close the loop

Every alert gets an outcome recorded: investigated and confirmed, investigated and clear, not investigated. Without that, precision is unmeasurable and the model cannot improve — and this is the step that quietly does not happen unless it is built into the workflow.

WHERE IT RUNS

On the plant network, in almost every case. Operational technology networks are commonly isolated from corporate IT and from the internet as a matter of engineering practice, which makes this a natural on-premise or air-gapped deployment rather than a cloud one.

That is not a limitation. Sensor inference is well within the reach of small models on modest hardware, latency to the floor is better, and the system keeps working when the site loses its connection — which for a plant is a functional requirement rather than a preference.

EARNING THE TECHNICIAN’S TRUST

ALERT PATH

Sensor history

abundant, poorly labelled
Reconstruct labels

from work orders and notes
Model

or anomaly detection if rare
Rank to capacity

what the team can act on
Work order

in the CMMS they already use
Outcome recorded

confirmed, clear, or ignored

Solid: the alert path Dashed: the outcome loop, without which nothing improves

The second box is usually the largest task in the project, and the last one is what makes precision measurable at all.

QUESTIONS

QUESTIONS — 3

Enough to cover several failures of the type you want to predict, across seasonal and load variation. Where you have the history but not the labels — which is the common case — the first phase is reconstructing labels from maintenance records, and that is worth doing even if the modelling never happens.

Then supervised failure prediction is not available and claiming otherwise would be dishonest. Anomaly detection against a well-characterised normal, combined with physics-informed limits, is the right approach — and it is a different and more modest promise, which is exactly why it should be described accurately at the outset.

It has to. An alert that does not become a work order in the system technicians already use does not become work. That integration is usually where the realistic timeline is set.

Keep reading

Air-Gapped Deployment

30-minute technical call · no deck