- Home
- Capabilities
- Predictive Maintenance
Capability
Catch failure while it is still a maintenance ticket.
The value is not in predicting that a machine will eventually fail. It is in predicting it early enough, and specifically enough, that someone can act during planned downtime instead of at 2am.
01 / The problem
Where this usually goes wrong.
Most predictive maintenance projects die on the same rock: not enough failures. A well-maintained asset fails rarely, which is the point, and rarely is exactly what supervised learning cannot work with.
The second rock is a warning horizon that is technically impressive and operationally useless. Six hours' notice is worthless if the spare part has a three-week lead time and the maintenance window is monthly. The horizon has to be designed around your logistics, not the model's convenience.
02 / What we build
The parts of the system.
- Sensor and log integration
- Vibration, temperature, current draw, pressure and controller logs, aligned to a common clock — which is rarely as straightforward as it sounds across equipment from different decades and vendors.
- Failure history reconstruction
- Work orders and maintenance logs turned into labelled failure events. This is usually archaeology through free-text notes, and it is where the real effort in these projects goes.
- Anomaly-first modelling
- Learning normal operating behaviour per asset and flagging departure from it, which works when failures are too rare to train on directly. Supervised models come later, for failure modes with enough history.
- Alerts routed into the maintenance system
- Predictions that arrive as a work order in the system your technicians already use, with the evidence attached. An alert in a separate dashboard is an alert nobody sees.
03 / How it is measured
What we agree to be judged on.
Set before the build starts, against a measured baseline, and reported honestly afterwards — including where the numbers are disappointing.
- Warning horizon
- Distribution of lead time between alert and failure, judged against your parts lead time and maintenance windows rather than in the abstract.
- False alarms per asset per month
- The number that determines whether technicians keep trusting the system. Two per asset per month will get it switched off.
- Coverage by failure mode
- Which specific failure modes are detectable with the sensors installed, and which are not. Being explicit here prevents false confidence.
- Avoided downtime
- Reconstructed from intervention records — what was caught, what it would have cost, and what it cost to catch.
04 / Honest limits
What this will not do.
Sudden failures with no mechanical precursor — an electrical fault, a foreign object, an operator error — are not predictable from condition data. We will say which of your failure modes fall into this category during the diagnostic rather than after the sensors are installed.
If maintenance history is not recorded in a usable form, the first phase is building that record, and useful predictions are a season away rather than a month. This is worth knowing before the budget is set.
05 / When it applies
You probably need this if:
- Unplanned downtime is a recognised, quantified cost
- Maintenance is calendar-based and either too frequent or too late
- Equipment already produces sensor or controller data nobody analyses
- Certain assets have a reputation for failing without warning
Recognising two or more of these is a reasonable trigger for a diagnostic. Recognising none of them is a reasonable trigger for not spending money here yet.
06 / Related
Often scoped together.
These capabilities share data, infrastructure or evaluation approach with predictive maintenance, and are frequently part of the same engagement.
Next step
Is predictive maintenance the right instrument for your problem?
The diagnostic exists to answer exactly that, including the possibility that the answer is no. It is time-boxed, fixed-fee, and the written assessment is yours.