Predictive maintenance operators are willing to trust

iConcept PowerTech operates power plants, transmission and distribution systems. Before we started, a failure surfaced when generation dropped, and diagnosing it meant putting an engineer in a vehicle and sending them to the site. The platform we built streams plant telemetry into a central grid system, forecasts downtime from it, and raises the ticket without a human. The modelling was the shortest part of the project.

The longer part was making the output something a control room operator would act on. A prediction nobody acts on has the same value as no prediction at all, and it costs considerably more to produce.

The false-positive budget

Operators have a tolerance for wasted trips and it is lower than most data teams assume. Send someone across a site for nothing twice and they begin reading the alerts sceptically. Do it four or five times and the alerts become background noise. Once that has happened you do not win it back by improving the model, because nobody is reading the output any more.

So the tolerance gets set as a number before anything is tuned. How many unnecessary dispatches a month is this operation willing to absorb in exchange for catching failures early? The figure comes from the operations manager, and it is usually small. The threshold is then tuned to that figure and the model is judged against it, rather than against whichever aggregate score looks best in a notebook. A model with worse headline accuracy and a false-positive rate inside the budget is the better system, and it is worth being explicit about that with the client before the first review.

An alert has to say what it saw

A probability on its own cannot be acted on. Told that a unit has a 78 per cent chance of failure, an operator has no basis for choosing between dispatching now, adding it to tomorrow's round, and ignoring it because that unit has been noisy since the day it was installed.

What works is stating the observation and the comparison. Which signal moved, over what period, against what baseline, and which comparable units did not move with it. An operator reading that can apply their own knowledge, and their own knowledge is considerable. They know which unit sits in shade after two o'clock and which one throws odd readings whenever it rains. Give them the evidence and they will filter a good share of the false positives for you. Give them a percentage and their only options are to accept or reject the machine.

Severity as an instruction

We express confidence as an action rather than a number, because an action is something an operator can be held to and a number is not. Three levels are usually enough: watch it, inspect on the next scheduled visit, dispatch now. Each level gets a definition agreed with operations before go-live, and each carries a cost the operations manager recognises.

Auto-ticketing was in the build from the start, which makes the whole thing measurable. Every alert leaves a record, and every record closes with an outcome: confirmed, not confirmed, already known. Those closure codes are the only honest evaluation set the platform will ever have. Historical training data tells you how the model performed on the past. The outcome codes tell you how it is performing this month, on the plant as it stands now, with sensors that have drifted since they were installed.

Trust in these systems is built in the first two months and it is not rebuilt afterwards. We now spend the early weeks in shadow mode, showing operators the alerts the system would have raised alongside what actually happened, and switching on dispatch only once the people who would be driving the van agree the alerts have been worth reading. It slows the launch by a few weeks. It is the difference between a platform that gets used and one that is politely ignored until the contract ends.