← THINKING

Why predictive maintenance stalled at the pilot

A decade of pilots produced accurate models and very few changed maintenance plans. The missing layer was never the algorithm.

Ask a reliability manager how many predictive maintenance pilots their site has run and the answer is rarely zero. Ask how many changed the maintenance plan and the answer very often is. The models were not bad. Several were genuinely good — a vibration classifier that flagged a bearing defect eleven weeks before failure, a thermal model that caught a fouling trend a technician had missed. The pilots were declared successful, and then nothing happened.

This is worth taking seriously rather than explaining away. The usual accounts — change resistance, poor data quality, insufficient executive sponsorship — are not wrong so much as incurious. They describe the symptoms of a structural problem as though they were its causes.

The structural problem is this. A maintenance plan is a document with an owner, a basis and a liability attached. Changing it is an engineering act. A model output is none of those things. Nothing in the pilot architecture converted the second into the first, so the gap had to be crossed by a person, informally, on their own authority — and no competent engineer does that twice.

The question nobody could answer

Every stalled pilot I have seen stalled at the same conversation. The model says advance the inspection on CH-02 by twelve days. The responsible engineer asks a reasonable question: on what basis?

The honest answer is that a model trained on historical failures assigned this pattern a high probability. That is a true statement, and it is not an engineering basis. It cannot be checked against the machine's design limits. It does not say which physical mechanism is progressing. It cannot be defended to an insurer, an auditor, or the engineer's own successor in three years. If the inspection is advanced and finds nothing, there is no record of why it was advanced; if it is not advanced and the bearing fails, there is no record of why it was not.

So the engineer does the rational thing. They note the alert, they do not act on it, and at the end of the pilot they report — accurately — that the tool did not change any decisions.

Three things the pilots were missing

None of them is a modelling problem, which is why a decade of better models did not fix it.

A canonical record of what the asset is

The design basis for most industrial assets exists — in a datasheet, a commissioning report, a vendor curve, a spreadsheet a contractor left behind. It exists in four incompatible vocabularies and none of it is reachable by the model. So the model reasons about a time series while the engineer reasons about a machine, and the two never meet. This is what the ontology is for, and it is unglamorous work that nobody funds because it looks like data cleaning rather than intelligence.

A constraint layer the model cannot talk past

An engineer trusts a recommendation when they know what it was checked against. A pilot that surfaces model output directly to a human has skipped the only step that would make the output actionable — evaluation against the asset's actual limits, with the result of that evaluation shown. Not as a confidence score, which is a property of the model, but as a physics verdict, which is a property of the machine. The gate is that step, and it has to be non-bypassable or it becomes advisory, and advisory means skipped under pressure.

An artefact that can be signed

Engineering accountability is personal. Someone's name goes on the decision, and that person needs a document recording what was known, what was calculated, what was assumed and what they concluded. A dashboard alert is not that document. Until the output of the system is an artefact an engineer can put their name to, the system sits outside the decision process no matter how accurate it is.

The uncomfortable implication

If this reading is right, then the industry spent a decade optimising the one component that was already adequate. The classifier was never the bottleneck. The bottleneck was that nothing downstream of the classifier could convert a probability into an engineering position — and building that is slower, less impressive in a demonstration, and considerably harder to sell than another model.

It also implies something about how the next attempt should be judged. The right question at the end of a pilot is not whether the model was accurate. It is whether any maintenance plan changed, who signed the change, and whether the reasoning behind it can be reconstructed two years later by someone who was not there.

By that measure most successful pilots failed, and the honest ones knew it at the time.

Read the manifesto