A predictive maintenance model that is accurate and ignored has delivered nothing. This is the usual outcome, and it is not a modelling failure.
Being told an asset will fail is a request to do something expensive and disruptive on someone else’s authority. Whether that request is granted depends almost entirely on things outside the model.
What an engineer is actually being asked
To take a working asset out of service, on a prediction, against a schedule already agreed with operations, with the cost landing in their budget and the consequence of being wrong landing on them.
Against that, “the model says so” is a weak argument — and correctly so. The engineer has context the model does not: this unit always reads high after a restart, this sensor has been drifting since March, this pattern appeared last winter and meant nothing.
What makes a prediction actionable
The contributing factors, ranked. Not a score, but which readings drove it and by how much. An engineer can evaluate that against what they know.
A comparison to normal. Normal for this asset, in this duty, at this time of year — not a fleet-wide average that flags every unit in the coldest month.
A time horizon. “Elevated risk” is unusable. “Likely within two to six weeks” can be planned around, and can be scheduled into a window that already exists.
A recommended action with a cost. Inspect, monitor, or intervene. Most alerts should resolve to “look at this during the next planned visit”, and a system that only ever escalates gets muted.
A route to disagree that is recorded. Engineers overriding the model is the most valuable feedback available — and if the disagreement goes into a phone call, it is lost.
False positives are the whole game
Alert fatigue is not a nuisance, it is the failure mode. A system that cries wolf is abandoned within weeks, and the abandonment is permanent — a second attempt inherits the reputation of the first.
Which means a conservative model that flags less and is right more is worth more than a sensitive one, at least at the start. Trust is built by being right about small things before anyone will accept a large call.
The foundations decide the ceiling
Most of this work is not modelling. It is finding that the same asset appears three ways across four systems, that maintenance history is in free-text work orders, that the sensor tag list was last accurate in 2019, and that failures were recorded as “repaired” without a cause.
Without a reliable record of what failed and why, there is nothing to learn from. This is the data strategy problem in another sector, and it is where the time goes.
How we build it
Every contributing factor logged so a person can disagree with a score and see why it said what it said. We built RailGard AI on that basis for safety-critical rail work, where a score has to be defensible line by line, and ECS Group Command holds the asset register, inspection status and certification that a model of this kind needs underneath it.
Getting operational forecasting into production? Get in touch, or read about our energy and utilities work.