Condition-based maintenance has an unusually high rate of quiet failure. The programme launches, runs for a year, and then one day nobody is looking at it any more. In our experience the detection method is almost never the reason.

One: the model was built on tags, not assets

If the monitoring is configured per machine, against individual tag names, it does not scale and it does not generalise. Every new asset is a fresh configuration exercise. Thresholds tuned on one pump have no defensible relationship to the next pump. Nothing can be compared across the fleet, because nothing shares a definition.

Monitoring defined once at asset-class level, against a model, applies to every instance automatically and improves for all of them when it improves for one. This is why the asset model work comes first even when the client arrived asking for detection.

Two: the detection does not know what the plant is doing

Equipment behaves differently at startup, at steady load, while load-following, in standby and during an outage. A threshold that is correct at steady state generates alerts every time the unit starts.

Those alerts are not wrong exactly — the value genuinely crossed the line — but they are not useful, and a system that cries wolf during every normal transition trains its users to ignore it. Operating-state awareness is not a refinement to add later; it is the difference between a system people trust and one they mute.

Event frames are the natural mechanism here: capture startups, trips and outages as objects, and detection can reason about them rather than being surprised by them.

Three: there is no path from detection to action

This is the one that kills most programmes. A deviation is detected. It appears on a dashboard that lives in a different system from the one maintenance planning uses. Nobody owns the response. No work order results.

After a few months of findings that lead nowhere, people stop checking. The programme is not cancelled — it just stops being part of anyone’s routine, which is harder to notice and harder to fix.

What the successful ones have in common

• Detection defined at asset-class level on a maintained model, not per machine
• Operating state understood, so normal transitions do not generate noise
• Alerts delivered where the people who act already work, not in a new tool
• A named owner for the response, and a route into the maintenance workflow
• Deliberate false-positive management, revisited rather than set once
• Trending of the rate of change, not just threshold crossing — direction is what gives planners lead time

The uncomfortable implication is that most of the work in a successful CBM programme happens before anyone chooses a detection technique, and most of the rest happens after. How we approach it.