Predictive maintenance is mostly a labelling problem

#Why the models are not the hard part

Given a labelled dataset of equipment states with failures marked, predicting failure is a well understood supervised learning problem. The difficulty is that on real industrial data, that dataset does not exist.

#Four reasons the labels are missing

Failures are rare by design. The whole point of a maintenance programme is to prevent them. A facility with a good programme produces very few positive examples, and the ones it does produce are heterogeneous.

Prevented failures are invisible. A technician noticed something, intervened, and the failure did not occur. The record says routine maintenance. That was a positive example and it is recorded as a negative.

Timestamps are wrong. A work order is dated when it was raised or closed rather than when the problem started. The gap can be weeks, which matters enormously when you are trying to align a label with a sensor window.

Free text. The actual failure description is in a comment field, written by different people using different vocabulary over twenty years, sometimes in more than one language.

#What to do about it

Three approaches, in order of how often they have worked for me.

Change the target. Instead of predicting failure, predict a measurable proxy with plenty of examples: an operating parameter exceeding a threshold, or a change in a derived health indicator. Less directly valuable and it produces a model you can actually validate.

Anomaly detection. Model normal operation, flag deviation, and accept that you are not predicting failure but detecting change. This needs far less labelled data and it produces false positives, which are only tolerable if the review cost is low.

Invest in labelling. Sit with the maintenance team and reconstruct real failure histories from work orders, comments and memory. It is slow, unglamorous, and the highest value work on the project. Data lifecycle work dominating machine learning effort is a well documented pattern [3] [1].

#Drift is guaranteed here

Industrial equipment is maintained, modified and replaced. Operating conditions change with season, product mix and demand. A model trained on last year's behaviour is describing a system that no longer exists in the same form, which is the standard concept drift problem [2].

That makes monitoring mandatory rather than optional. Track the input distribution as well as the output, because a shift in inputs is the earliest available signal that the model is being asked questions it was not trained on.

#Validation, honestly

A model claiming to predict failures thirty days ahead, validated on a handful of historical failures, has enormous uncertainty on that claim. Reporting a single accuracy number for it is misleading.

The computational science community has been direct about this: scaling twins from individually tuned models to fleets requires uncertainty quantification that mostly does not exist yet [5]. A production readiness rubric is a useful discipline here, because it forces the questions about data validation and monitoring that get skipped [4].

#The organisational part

A model that flags a machine is asking somebody to do work. If the maintenance team does not trust it, they will ignore it, and after enough false positives they will ignore it permanently.

Involving them in defining what counts as a useful alert is not stakeholder management. It is the difference between a deployed model and a dashboard nobody opens.