Abstract
Almost all industrial AI attention goes to the front of the job. Diagnosis, scope, planning. The back of the job produces the evidence the front will run on next time, and it is where the loop is broken in nearly every plant. This paper argues that closeout quality is the highest-leverage and least-addressed point in the maintenance information cycle, that no amount of front-end sophistication compensates for a record that cannot say what was actually found, and that the failure is usually not a missing diagnosis but a diagnosis that never got written anywhere the next person could reach it.
Three years, every three to four weeks
I was working as a millwright contractor running out of Slave Lake, serving oil sites all over northern Alberta. One of the pumping stations had a pump with a mechanical seal that kept blowing. The site was a good three hours north of us. Six hours of driving round trip, plus an hour or two to change the seal.
We went up and changed that same seal every three to four weeks. For about three years.
Every single time, we told them what was wrong. The only way a seal blows like that is you are sucking air, drying the pump out, trying to pump nothing. Mechanical seals do not last under that. Something was wrong on their side.
And every single time they refused it. No, that is not what is happening. They said we were installing the seals wrong. They demanded warranty on every failure. They never got warranty, because we kept telling them what was actually wrong, so the site paid for the seals and the call-outs, every three to four weeks, for three years.
Then one trip there were contractors all over the site changing a bunch of plumbing. We changed the seal as usual and went home.
Some time later, out there on a different job, I realised we had not been back to that pump in quite a while. I asked an operator about it. Ever since they changed the piping you have not blown that seal, what happened?
He said: "Yeah. I don't know. They found something wrong."
And he walked away. We never went back to change that seal again, and nobody ever told us what was wrong with the pipe.
Four failures in one story, and only one of them is technical
Pull that apart, because the loop breaks in a different place at each end and the breaks compound.
Recurrence is data, and the front end could not use it. Same part, same failure, every three to four weeks, three dozen times over. Nothing about a bad batch or a bad installation explains periodicity like that. The failure pattern was the diagnosis, repeating itself out loud, on schedule, for three years. Any system holding that history had the answer sitting in it. What none of them had was a query that asks whether the same thing keeps happening, because a system that counts jobs closed will never trigger on jobs recurring.
The diagnosis was not missing. This is the part that separates this from an information-capture problem. Nobody had to dig for it and nobody had to hope somebody read a note. We handed them the answer, in person, roughly thirty-six times. Worth saying plainly that those call-outs were steady billable work for us, and we kept trying to hand the customer the way to stop paying us anyway.
It was refused for what accepting it would cost. "Your part is defective" is somebody else's problem and somebody else's bill. "You are running the pump dry" is theirs. Warranty was not a theory about the failure. It was a way of not being responsible for it, and it kept getting reached for long after it had stopped being plausible.
And when the fix finally happened, it was never written down. This is the failure this paper is about. Somebody found the pipe fault and corrected it. The only trace that event left in the world was an absence, the call-outs stopping. No closure note went back to the crew who had diagnosed it correctly for three years. The operator who told me about it did not know what had been found. The site paid three years of seals, freight, driving and contractor rates to purchase one piece of knowledge, and then did not record it.
Ask what that asset history says today. It says the seal was replaced about thirty-six times and then stopped being replaced. The reason is not in there. Anything reading that record now, human or otherwise, would conclude the seal problem resolved itself.
The closure note is a diagnostic input
The framing that fixes this is simple to state and hard to adopt.
A closure note is not a record of what happened. It is the input to the next diagnosis.
Write it that way and its contents change completely. It stops being an account of the labour performed and becomes a description of the condition found. The measurement, not the fix. The wear pattern, not the part number. What was ruled out, not just what was done. What you think is causing it, even when nobody asked and even when you are not certain.
That last one matters more than it sounds. On the pump station, the diagnosis lived in a truck cab and in conversations at a site gate. It was correct for three years and it never once entered a record, so it could not be checked later, could not be escalated by anybody who was not standing there, and could not be vindicated when the pipe change proved it right.
An unrecorded correct diagnosis and a missing diagnosis are the same thing to everyone downstream.
What must be captured, and what usually is not
IBM's work on evidence-driven reasoning for industrial maintenance points the direction, integrating maintenance language, operational behaviour and engineering failure semantics to produce explanations grounded in evidence. The constraint on any such system is the language it has to read.
Six fields would change what these systems can do, and none of them requires new instrumentation.
What was found, as distinct from what was done. "Changed mechanical seal" is what was done. "Changed mechanical seal, faces heat damaged, consistent with dry running, suspect air on the suction side" is what was found. The first closes a ticket. The second is evidence.
Measurements taken, with units, even when they were in tolerance. An in-tolerance reading is evidence too, and it is the reading that lets a future diagnosis eliminate something.
What was ruled out. The most valuable sentence a tradesman can write is often the one recording what was fine. Seal installed to spec, faces checked, not an installation fault. That sentence got said out loud on that site for three years and never got written once, which is exactly why the warranty argument could keep being made.
Whether this is a repair or a holding action. We had a vibrating conveyor cracking itself apart, stress fractures all over it, and those things rip themselves apart fast once they start. The replacement was weeks out, so I got the welders in to weld the hell out of whatever they could, an explicit stopgap to limp it to the next down day. Next down day I scheduled them to hit it 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. It was nowhere near fixed and was not going to be, because it needed replacing, and we were chasing our own tails hoping it did not let go before the new one arrived. He was not being stupid. He defaulted to running equals done because the system let him. The distinction lived in a verbal aside instead of a completion state. One field, marked TEMPORARY, recurring until replacement, would have ended that argument before it started, twice.
Verification, and when. Did anybody come back and check, and what did they find. A fix without a re-inspection is a hypothesis. On that conveyor the honest completion state carries its own verification schedule with it, re-inspect every window until replacement, and that is what a holding action should always look like.
What transfers. Does this apply to the other assets of the same type in the building, and to the ones that are not the same type but sit in the same conditions. This is the field no CMMS has and the one that makes a record worth keeping.
Both ends or neither
The argument of this paper is that front-end AI cannot outrun back-end record quality, and the pump station proves it in both directions.
A diagnostic agent reading that asset's history would have concluded, correctly given its inputs, that a seal was replaced on a regular cycle and then stopped needing replacement. It would have been fluent, confident and wrong, and it would have had no way to know, because the one fact that mattered in three years of that asset's life was never entered.
Conversely, a plant that fixes only its closeout discipline and buys nothing gets most of the value anyway. One record in three years containing the words "suspect air on the suction side, recommend the piping be checked" would have put the diagnosis somewhere an engineer, a new supervisor, an insurer or an auditor could find it. It cost nothing. Nobody was stopping anyone from writing it. There was just no field for it and no expectation that anybody would look.
If you are going to do one end, do the back one. It is cheaper, it needs no procurement, and it determines what the other end can ever know.
There is a companion failure worth naming, because fixing closeout alone does not close the loop. A record can be complete, photographed, timestamped and flagged urgent and still change nothing, if no part of the organization has the job of reading it. That is the meat plant shaft, told in full in Operational Memory, where a perfect archive sat beside a shaft that failed anyway. Good notes are necessary. A reading obligation is what makes them worth writing.
The condition your plant is actually in
Here is what it looks like when somebody does read.
At a cheese factory I worked at, the warehouse crew hand-wrapped every pallet in shrink wrap before it went on a truck. I watched men line up at an empty patch of floor waiting their turn to drop a load and wrap it by hand. I had worked in a plant with machines built for exactly that job. I took it to the plant manager and got dismissed. He had looked into it before, they were too expensive.
That did not add up, so I went home that night and found three of them on eBay for about a thousand dollars. Printed the listings, brought them in the next morning. Dismissed again, and now the reasons were no space and no real savings.
So I wrote a report. Not a suggestion, a report. The machines and the price. An estimate of the man-hours going into hand-wrapping and the dollar savings on manpower alone, which justified the purchase on its own. Then a point-by-point answer to every objection. I measured the void space they were already using and compared it against the blueprint footprint of the machine to prove the room existed. I laid out the power requirements and where to draw from. I estimated the operating cost. All of it annualized.
The company had a suggestion box, and the owner personally collected and read them. I put the report in the box. It barely fit through the slot, because the box was not built for actual reports. I did not put my name on it.
End of the month the owner and the plant manager came to my department holding it. Was I familiar with this. Yes. Did I write it. Yes. They looked surprised. They said thank you, this is well thought out. I said that is great, thanks, but I have to get back to work.
A week later three machines showed up and were installed. Not the used ones off eBay. New ones.
That is the mechanism of this paper in one story, and I want to be careful about which part is the lesson. It is not that I wrote a good report. It is that there was exactly one channel in that building where written evidence got read by somebody whose job included reading it, and the evidence had to be routed to that channel before it could do anything. Through the normal path it had already been refused twice, on grounds the report itself answered.
And the same suggestion box awarded its monthly prize by pulling a name out of a hat. The month that report went in, the gift card went to a suggestion to change the radio to a different station.
That is not a joke at anybody's expense. It is the failure in its purest form. A mechanism installed to hear from people processed what it received by lottery, because a lottery is fair, easy to administer, and requires nobody to read anything, judge anything, or defend a decision. The reading obligation was absent from the one system built for reading.
Which is the condition most plants are in. Competent people who have stopped expecting anybody to look, writing "replaced bearing" because they have learned that longer notes disappear unread. They are not being lazy. They are optimizing correctly against the response they have observed.
Which gives the actual first move, and it costs nothing. Read what you get, and be seen doing it. The first time a tradesman writes a detailed closure note and somebody acts on it, calls a meeting or orders a fix or changes a procedure, he will write another one. The first time he writes one and nothing happens, he will write "replaced bearing" forever.
You cannot buy your way out of that, and no system can generate evidence that nobody was willing to write down.
Conclusion
The maintenance evidence loop has two ends and the industry is working on one of them.
Better diagnosis at the front is worth having. It is worth much less than it appears, because it runs on records produced at the back by people who have concluded, on good evidence, that nobody reads them.
Fix the closeout. Ask for the finding rather than the fix, the measurement rather than the part number, the suspicion rather than only the certainty, and the re-check rather than the assumption. Then read what comes back, visibly, so the next one gets written.
Three years of seals, and the answer was in the truck the whole time. Nobody ever wrote it down, so as far as that site is concerned it was never known.
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
- 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
- SAP, “SAP Business AI: Release Highlights Q2 2026,” July 20, 2026. https://news.sap.com/2026/07/sap-business-ai-release-highlights-q2-2026/