Abstract
Every industrial AI proposal assumes the maintenance record means what it says. It usually does not. Failure codes are selected to close a screen, closure notes are abbreviated because nobody reads them, and some of the most serious faults in a plant never generate a record at all. This paper argues that maintenance data quality is not a preparatory task to be completed before AI arrives but a permanent constraint that should determine the maximum authority any system is granted, and that the most dangerous defect in a maintenance record is not a wrong entry. It is an absent one.
The healthiest machine in the plant
The dryers were big machines. Porous conveyors carrying material while hot air blows through, on three levels. The top level of one of them tripped an overload every single time it started.
I found out by accident, because I happened to be standing there when the operator called to start it, and the operator was inside the guard kicking the sheave to get it going.
I told him to get out of there and asked what he was thinking. He said it will not start otherwise, you just get a motion alarm.
The other operators had been doing it so long they had a system. Just kick it.
Not one work order had ever been generated. The operators knew. Electrical knew, had looked at it, and could not work it out. The PLC contractor knew. The fault ran for a very long time with zero documentation anywhere in the building.
Now ask a maintenance AI about that dryer. It reads the CMMS and finds an asset with no fault history, no repeated failure codes, no trend, and no open work. It will tell you, fluently and correctly given its inputs, that the dryer is one of your healthier machines.
The record was not wrong. The record was empty, and empty reads as fine.
That is the ceiling, and no model architecture raises it. A system reasoning over maintenance history cannot see a fault that produced no history, and it has no way to distinguish an asset with no problems from an asset whose problems were absorbed by the people standing in front of it.
Why records go missing
Three mechanisms, all of them rational from where the person is standing.
The workaround is cheaper than the report. Kicking the sheave takes four seconds. Writing a work order takes ten minutes and produces, in the operator's experience, nothing. He is optimizing correctly against the response he has observed.
The report was made and nothing happened. I once found a guard that had fallen off a machine and worn into a three-inch drive shaft like it was on a lathe, down to maybe a quarter inch of steel. I photographed it, emailed my supervisor, flagged it urgent, and put in the work order. It got ignored, and two or three weeks later the shaft failed.
That plant now has a maintenance record that says the shaft failed, and a separate, never-connected record saying somebody predicted it. The data is not missing. It is disconnected, which for any automated reasoning is the same thing.
Nobody defined what the record was supposed to say. We had a vibrating conveyor cracking itself apart and I got welders in to weld the hell out of it as a stopgap to limp it to the next down day. Next down day I scheduled the welders again, and the plant manager was angry because I had told him it was fixed.
I had not. I told him it was OK to run until the next down day. The distinction lived in a verbal aside, not in a completion state, so he defaulted to "running equals done" because the system let him. One line on the work order, TEMPORARY, recurring until replacement, would have ended the argument before it started.
He was not being stupid. The record had no way to hold the difference between a repair and a holding action, so the difference evaporated.
The failure code problem
The failure code is the field most industrial analytics depend on and the field least likely to be correct.
Codes get chosen from a dropdown, often by whoever closes the record rather than whoever did the work, frequently from a list that has not been revised since the system was commissioned, and under time pressure from someone whose actual objective is to make the screen go away.
Mean time between failures computed on that data is arithmetic performed on fiction, and it inherits all the authority that arithmetic carries.
This is worth stating plainly because it is the quiet assumption under most predictive maintenance proposals: that the historical failure record describes what actually failed. In most plants it describes what somebody selected.
Why AI amplifies rather than corrects this
A language model reads the record as text and has no mechanism for representing that the text is unreliable. It will summarize a poor failure history into a fluent, confident and entirely wrong account of what has been happening to an asset.
The fluency is the danger. A bad spreadsheet looks bad. A bad narrative looks like insight.
There is a second-order version that is worse. Automated systems are very good at doing exactly what they were configured to do, indefinitely, past the point where any human involved thinks it makes sense.
I once had a planner put in a standing order for ten totes of dry ice a week, out of spite, after he quit. I had asked for eight as a starting point, we used four, and I asked repeatedly for it to be cut back. It kept coming. I took it to the plant manager. It kept coming. It reached more than forty totes on the floor before anyone acted, and by then the dry ice had clumped solid and we had been paying rental on the totes the whole time.
The system did exactly what it was set to do, for weeks, long after everyone knew it was insane, and the only reason it was ever caught is that dry ice produces a physical pile you have to walk around. Most automated waste does not produce a pile.
The research is pointing the right way
Recent work is starting from a better premise. IBM Research describes a Condition Insight Agent that integrates maintenance language, behavioural abstractions of operational data and engineering failure semantics, constructing evidence deterministically and running a verification loop intended to suppress unsupported conclusions. Crucially, the reported deployments were built on incomplete and heterogeneous CMMS data rather than clean datasets.
That is the right test. Any system demonstrated on a tidy dataset has been demonstrated on a plant that does not exist.
ConMem's contribution-aware approach to long-horizon inspection logs makes a related admission: that most of what is stored does not deserve equal standing, and deciding what matters is itself the hard problem.
Measure the data, then bound the authority
Data quality should be a standing metric rather than something discovered during a project. Six measures, all cheap to compute from an export:
- proportion of closures carrying substantive notes
- proportion of failure codes that are the default or "other"
- proportion of assets with duplicate identities
- age distribution of referenced drawings and manuals
- proportion of assets with no recorded fault in the last two years
- number of urgent findings raised and closed with no linked action
The last two are the ones nobody computes and the ones the stories above demand. An asset with a clean two-year record is either genuinely reliable or the dryer, and the difference is not visible in the data. It is visible by walking out and asking an operator whether he has a trick for starting it.
Those numbers should then bound what a system is permitted to do. Where notes are empty, an agent may summarize but not conclude. Where failure codes are unreliable, it may retrieve but not predict. Where an asset has no fault history at all, it may say nothing about that asset's health whatsoever, and it should say why.
That is the non-compensatory logic ADMITBench applies to advisories, moved upstream to the data the advisory rests on.
Conclusion
The industry keeps proposing to fix data quality later, after a pilot proves value. That order is backwards, because the pilot's apparent value is manufactured by the same data problem it was meant to survive.
Publish the six numbers first. They will be worse than expected, and they will tell you precisely which claims the organization is not yet entitled to make.
And remember which defect actually hurts. A wrong entry can be caught by a contradiction. A missing entry cannot be caught by anything, because there is nothing there to contradict. The worst machine in the building will look like the best one, and the only person who knows otherwise is standing inside the guard, kicking it.
References
- IBM Research (O’Donncha et al.), “Evidence-Driven Reasoning for Industrial Maintenance Using Heterogeneous Data,” ACL 2026. https://research.ibm.com/publications/evidencedriven-reasoning-for-industrial-maintenance-using-heterogeneous-data
- Misra, Vyas, Gutta & Mercangöz, “ADMITBench: A Safety-Governed Reference Framework for Evaluating the Admissibility of Industrial LLM Advisories,” 2026. https://arxiv.org/abs/2608.03866
- Liu et al., “ConMem: Contribution-Aware Memory for Long-Horizon Manufacturing Inspection Logs,” 2026. https://arxiv.org/abs/2607.28126
- Hsu et al., “Cache-augmented multimodal generative AI for energy-aware predictive maintenance,” Computers & Industrial Engineering, 2026. https://www.sciencedirect.com/science/article/pii/S0360835226003517