Perspective
Predictive Maintenance Starts With a Failure History Your Plant Can Trust
A model can only anticipate failures that have been described. We test your records first, so the first AI feature is built on a history that supports it.
4-minute read5 November 2026
In Brief
- A sensor trend means little until it can be tied to an outcome. Work orders that cannot say what failed and why leave a model with signals and no lessons.
- We see four actions: code failures by component, mode and cause, make those fields mandatory at closure, read the codes weekly, and score a model on your own examples before buying one.
- Thinqmesh builds the AI feature with an evaluation set from week one, so you see a measured score on your own data. The first working feature arrives within four weeks.
Proposals for predictive maintenance usually start with hardware and software: sensors on the critical machines, a data platform, a model. The maintenance record comes up later, often as a data-cleaning task. Our view is that this order is wrong for any plant whose work orders cannot say what failed and why. Such a plant gains more from its first budget by repairing the failure history, even if the first model arrives later.
A Sensor Reading Becomes a Prediction Only Through the Record
A rising vibration reading on a gearbox is a prediction only when it can be tied to an outcome: this reading, on this kind of gearbox, under this load, was followed by this failure after roughly this many running hours. The signal comes from the sensor and the outcome comes from the maintenance record. An experienced fitter can fill gaps from memory, and a model cannot.
The record weakens in ordinary ways. Jobs are booked against a whole line, causes fall into an other category, small repairs appear only in a production log, and good preventive practice means critical equipment shows few true failures. The cost is a model that learns the maintenance schedule, alerts that operators learn to ignore, and a budget spent before the plant could use it. A tested use case and a better history put the effort in the right order.
Four Actions That Give a Prediction Something to Learn From
Better coding helps your reliability work from the first month, whatever you later decide about models.
Record Failures by Component, Mode and Cause
Bearing replaced says what was done. It does not say what happened to the bearing.
For one equipment class we agree a short list of failure modes that a fitter can use at two in the morning, and tie each work order to the item actually maintained. The history can then show whether two failures happened on the same gearbox, and what the machine was doing beforehand.
Get started
- Choose the equipment class whose stoppages cost the most.
- Draft about ten failure modes for it with a senior fitter.
Make the Fields Mandatory at Closure, and Read Them Weekly
Codes that no one reads decay quickly, so a supervisor reviews them each week.
Component, mode, cause, running hours and downtime are completed before a job can close. Small repairs that a shift crew clears and restarts are captured as well, using the same asset names as the production log, so the history reflects the stoppages the plant lived through.
Get started
- Choose the five fields that must be filled at closure.
- Name the supervisor who reviews the codes each week.
Separate a Failure From a Precaution
A part replaced early records how long it was used, which differs from how long it would have lasted.
We add a field that distinguishes a part that failed from one changed as a precaution. A model trained on the second kind mostly learns the maintenance schedule. With the distinction recorded, the data shows what the machine did, and the true failures become visible.
Get started
- Add a failed or replaced-as-precaution field to the work order.
- Review fifty past orders and mark each one.
Score the Use Case on Your Own Examples First
An evaluation set shows whether AI or conventional software is the right tool for this job.
We test candidate answers and alerts against real cases from your records and report a score. Routine condition monitoring on critical machines can continue in parallel, since fixed alarm levels need no model, and each alert's finding is logged so the plant learns which alerts justified a stoppage.
Get started
- Pull three years of work orders for the chosen class.
- Check fifty of them for component, mode, cause, downtime and precaution.
How Thinqmesh Solves This
Week one produces an evaluation set and a measured score on your own examples. That shows whether AI or conventional software is the right tool before further investment.
- Week 1
An Evaluation Set on Your Own Data
We collect real examples from your records and score the use case. You see whether the history supports the feature and where it needs further work.
- Week 2
The Feature, Built on Your Data
The first feature is built against that score. The model is chosen on answer quality, running cost and where your data may go.
- Week 3
Permissions and an Activity Record
The feature sees only what each person is permitted to see, and an activity record is kept. Anything high-stakes keeps a person approving the result.
- Week 4
A Working Feature, Monitored
The first working feature runs on your data. Quality and cost are tracked from the start, so any change is seen early.
You finish with a working feature on your own data, a score that measures it, and monitoring of quality and cost. The full engagement runs to six weeks, ending with the feature in use.
