Your predictive maintenance model is right 70% of the time.
That's exactly why the maintenance team stopped trusting it.

A predictive-maintenance model that's right seven times out of ten sounds like a win in a vendor pitch. On a plant floor, it's often the exact reason the maintenance team stops looking at the dashboard at all. How can being right most of the time make a tool less trusted, not more? We've watched this happen often enough to know the answer isn't about the model's accuracy.

01  ·  The math nobody puts in the pitch deck

Real equipment failures are rare, which is good for the plant and brutal for a classifier's precision. When failures are rare, even a model with a modest false-positive rate ends up firing far more false alarms than true ones in absolute terms, simply because there are so many more healthy days than failure days for it to misjudge. On one line we audited, that showed up as a 31% false-positive rate, which sounds almost respectable until you translate it into what the maintenance team actually experienced: roughly one in three call-outs for nothing.

Nobody disables the model when that happens. They just quietly stop responding to it, which looks identical to "we have predictive maintenance" on a slide and is functionally identical to having none.

02  ·  Why accuracy alone doesn't earn trust

The instinct is to treat this as a model-quality problem and go chase a better accuracy number. That helps, but it's not the actual lever. A maintenance technician doesn't decide whether to trust an alert by checking a model card, they decide based on what happened the last three times they acted on one. Trust is earned through explainability (why did it flag this specific bearing), calibrated confidence (is this a 55% guess or a 95% one, not a flat yes/no), and a visible track record the tool has to keep up in public, not a number that lived in a validation report nobody on the floor ever saw.

$ audit alerts --window=6mo --model=v1
alerts fired ........................ 142
confirmed failures ..................... 9
false positive rate .................. 31%
maintenance response rate ............ 12%  (94% at launch)
# the team isn't ignoring the model. they're ignoring the noise.
$ deploy --model=v2 --uncertainty=on --explain=on
alerts fired (90d) ................... 34
confirmed failures ..................... 8
false positive rate ................... 9%
maintenance response rate ............. 88%
# same sensors. same plant. different alert.

03  ·  What actually changed between v1 and v2

1. 01Confidence, not a binary alert. A calibrated probability instead of a flat "this will fail" lets maintenance triage, schedule the 60%-confidence flag for the next planned stop, and drop everything for the 95% one.
2. 02A reason attached to every flag. "Flagged because this bearing's vibration signature matches four prior failures" gets acted on. A bare score from a black box gets ignored, because there's nothing in it a technician can verify against what they already know about the machine.
3. 03A visible scoreboard. The model shows its own hit rate over time, on the same screen as the alert. Trust is something a tool has to keep earning in public, not something it gets to claim once in a validation report and coast on.
4. 04A feedback loop back into the model. Every override and every confirmation retrains it. The false-positive rate keeps dropping after launch instead of staying frozen at whatever it was the day the model shipped.

04  ·  The real cost of getting this wrong

The expensive failure mode here isn't a bad model, it's a good-enough model nobody trusts anymore, because it produces false confidence at the org level: leadership believes the plant has predictive maintenance, the line still fails without warning, and the postmortem discovers the alert fired three days earlier into a channel nobody was reading. That's a worse position than having no model at all, because at least "we have no predictive maintenance" is honest about the risk.

So the deliverable was never really "a model that predicts failures." Any team can ship that. The actual deliverable, the one that changes what happens on the floor, is a model the maintenance team believes enough to act on the next time it's uncertain, not just the first time it happens to be right.