Abstract
Industrial AI is becoming capable of reading work histories, proposing work, estimating resources, and creating or modifying maintenance records. That makes a neglected question more important: is the work actually ready to be executed? This paper proposes a four-gate Maintenance Readiness Review covering evidence, execution, operational conditions, and authority. The purpose is not to give AI another scorecard. It is to create a disciplined stop/go mechanism that exposes missing information before bad assumptions become scheduled work. The argument is illustrated throughout with failures I watched happen, because the framework is not a theory. It is a description of how jobs actually come apart.
A day that looked good to go
We had a planned down day to swap the camelback chains on the log decks. Three contractor crews, because the window had to be hit and one crew could not do it in the time.
On paper it was ready. All the chains were staged. Torches were out. Crews were onboard. Everything you could look at and count was there, and everything that mattered was something nobody had looked at.
There was one crane. Nobody had thought about that. Three crews, one crane, so somebody is always standing around waiting to fly their chains up. They had been given two torches on the assumption three crews would share them, and competing contractors do not share. I watched them fight over the torches, unplug each other's welders, and deliberately tie up the crane so the other crews could not lift. The lockout crawled, because three separate companies meant three sets of paperwork and the whole isolation run three times over on a deck packed with bodies. Nobody had confirmed the guys were rated to run the iron they were grabbing.
Then a crew that was behind and rushing cut the worst corner of the day. Instead of pulling a chain the right way, they hooked the crane straight to it, caught it on the catwalk, and ripped thirty or forty feet of catwalk out of the building. With a camera pointed right at them. Then lied about it.
The chain was fine. The catwalk had to be cut out and replaced. That crew was sent home.
Add it up: the shutdown for the safety investigation, the extra down days to finish the chains, the tear-out and reinstall of the catwalk, and the production lost working around a missing catwalk until it was back. The better part of a month, out of a day that looked good to go.
Not one of those failures was a maintenance problem. Every one of them was a readiness hole that nobody had a place to write down.
The problem is not a lack of recommendations
Maintenance systems already produce more recommendations than most plants can convert into good work. A notification, a condition-monitoring alert, an inspection finding, or an AI-generated advisory may identify a real problem and still never become an executable job.
The missing step is usually hidden inside planning. Confirming what is known, what remains uncertain, what resources are required, whether the plant can tolerate the intervention, and who is permitted to advance it.
Industrial AI makes this gap more visible, because modern systems move quickly from retrieving information to transacting on it. IBM Maximo 9.2 supports agentic workflows and MCP tools that can retrieve information, change work-order status, and create follow-up work orders. Oracle provides a conversational Maintenance Work Order Builder that creates, updates and retrieves work orders. These are useful capabilities. They also remove the friction that used to separate a plausible suggestion from an official maintenance record.
When creation becomes cheap, verification becomes valuable.
What "ready" actually means
The review uses four gates. Not ten dimensions, not a weighted index. Four questions, each of which can stop a job on its own.
Gate 1: Evidence readiness
Do we know enough to justify the proposed work?
This gate examines the symptom, the asset history, the measurements, the inspection findings, the freshness of the data, the contradictions, the assumptions, and the unresolved unknowns.
The thing that makes this gate hard is that evidence usually looks fine right up until it isn't. I was pulling the cap off a high-pressure pump once. The gauge read zero, so I trusted it, and I loosened the nuts closest to me first. Wrong order. The gauge was wrong, there was pressure behind that cap, and when the gasket let go the cap stayed tight at the back and gapped on the near side. It aimed the jet straight at my face. It blew up under my eyelids and into my mouth, knocked me on my ass, and soaked me head to toe in salt water. My eyesight took a while to come back. I still do not know what the pressure was. It could easily have killed me.
Years later I caught an apprentice about to pull a cap the same way, and I told him to loosen the back nuts first. He asked why. Because if there is pressure behind it, it blows a hole in the wall instead of your face. He said the gauge reads zero.
Yeah. But what if the gauge is wrong?
Same work, same time, done in a different order. That is the whole of evidence readiness. You do not build the method around the instrument being right. You build it so that being wrong is survivable, and then you go check the instrument anyway.
The industrial version of a bad gauge is a work order that describes a symptom nobody went and looked at. Here is how a part gets ordered in most plants: the tradesman says he needs it, the planner looks it up in the books or the computer, orders it, and builds the schedule around the supposed delivery date. Nobody in that chain verifies anything. Not the part, not a measurement. So it shows up wrong, with the line down, and a crew standing there holding a part that does not fit.
After that happened to us a few times we made a rule. You cannot trust the books. Anything like this gets its size verified before the order goes in. And it did not matter who did it. Usually a millwright put a tape on it. Once in a blue moon a planner came down himself.
That last part is worth sitting with, because the fairness of it matters. It is technically the planner's job to verify. But most of the time the planner does not know where the machine is or how it works, and asking him to verify a measurement he cannot physically get to is the system failing him, not him failing the system. So design the verification step in, and route it to whoever can actually perform it. It does not matter who does it, as long as there is verification.
Gate 2: Execution readiness
Can the work actually be performed?
Scope, sequence, labour, tools, materials, access, isolation, permits, special equipment, vendor requirements, and completion criteria.
We had a vibrating conveyor replaced once and the replacement arrived the wrong length. I do not know whether anyone measured it or measured it wrong. I had to retrofit both the infeed and the discharge to make it fit, and it took the line down for an entire week. A sixteen-hour scheduled window became an unplanned week, because the part was wrong.
There is a second failure hiding inside the first one. That machine would rip itself apart in a day if anything was off, and it was on a once-a-month inspection frequency. Nothing in the system captured how critical it was or how fast it could fail. The inspection work orders captured neither. That is what got us into building a reliability matrix, which turned out to be a fancy name for what I was already doing in my head, put on paper. Effective tool. We overpaid the outside consultants badly for it.
Execution readiness also fails in a quieter way that no system will ever show you. Down day, a crew up on a deck changing out a set of rails. Big, heavy, worn-out things. I came up at coffee and they had been there for hours and done nothing. Nothing. I asked what was going on and they told me the rails were too heavy, they could not do it, so they had just sat there and waited.
They did not call anybody. They did not try another way. They did not flag it. They downed tools and parked it while the window bled.
Half the time that is not laziness. They are stuck and too close to it to see the way through. But a stuck crew will not come and find you, and the cost of a crew quietly parked is invisible until you walk up on it. The plan does not run itself.
Gate 3: Operational readiness
Is this an appropriate time to perform the work?
A job can be technically complete and still be wrong for today. The plant may lack redundancy, production may not be able to release the equipment, a shared crane may be committed elsewhere, or a different outage window might reduce total risk.
The camelback chain day was an operational readiness failure dressed up as a contractor problem. One crane, three crews. Nobody clocked it, because a crane is not a part and there was no field on anything that asked who else needs it.
We had the same disease in miniature a while later, and it was almost funny. We planned to use the one skid steer for a waste-conveyor changeout. Went to do the job, and it was gone. Production had it for down-day cleanup, because of course they did, and nobody had reserved it.
After the crane day and the skid steer we built an asset-reservation system and started running real down-day meetings. Not just planners. Area leads and crews too, reserving the iron the same way we reserved the window, and either calling in more when we needed it or planning to work around whoever already had it.
That is what operational readiness is. Not "is the equipment available," but "who else needs this, and have they been asked."
Gate 4: Authority readiness
Is the person or system permitted to advance the action?
Role permissions, procedural approvals, safety boundaries, escalation requirements, and the reversibility of the proposed action.
I was told, flat out, that all the hands on site were certified to run the telehandler. I checked one down day. Not one guy was. Not one, and I had been told they all were.
Contractors will actively lie about certifications, or pass along a lie somebody told them, because "yeah, he's ticketed" is the answer that gets them on site. The day you find out otherwise is the day the machine is on its side, or a man is under it.
A ticket is a piece of paper. Ask to see the paper.
The same logic applies exactly to a software agent. "The agent has write access to the CMMS" is the software version of "yeah, he's ticketed." It is a claim about permission that nobody has looked at, covering four or five genuinely different actions with genuinely different consequences.
Readiness is a minimum, not an average
This is the part most likely to be argued with, so it is worth stating plainly.
A job that is green on three gates and red on one is not seventy-five percent ready. It is not ready.
Averaging is how organizations manufacture false confidence out of true data. Every input to that average can be accurate and the output can still be a number that gets a crew sent to a job they cannot do. The camelback chain day would have scored beautifully on any weighted index. Chains staged, crews onboard, torches out, window approved. One red gate, three green ones, eighty-something percent, go.
So the review returns three states and nothing else. READY, CONDITIONALLY READY, or NOT READY, and the state of the job equals the worst state present.
Each state comes with explicit blockers. A planner needs to know that isolation is unconfirmed, that a critical drawing is obsolete, that a seal kit is not physically on site. A planner does not need a decorative score of 73.4 percent.
This approach lines up with where industrial AI evaluation research is going. ADMITBench, a 2026 reference framework for evaluating industrial LLM advisories, assesses proposed actions using non-compensatory checks around evidence, authority, procedure and consequences. Non-compensatory is the technical term for what a millwright would call not being able to talk your way out of it. Excellence in one dimension does not cancel failure in a critical one.
The job that cannot be made ready
Every review generates an awkward category. Work that is clearly necessary and cannot reach READY, because something is genuinely unknown.
There are two obvious things to do with those jobs and both are wrong.
Scheduling it anyway exports the unknown to the floor. The crew arrives, finds the job is not what was written, and the plant absorbs the cost as an execution overrun, which is exactly the wrong place to book it.
Returning it to the backlog is worse, because it disappears. The job ages, the condition progresses, and the record shows a plant with a healthy backlog rather than a plant carrying an unresolved unknown on a critical asset. Nothing in any system distinguishes a job waiting for a window from a job waiting for information nobody is gathering.
The third option is a discovery task. Small, separately scheduled, and with exactly one deliverable: an answer. Open the gearbox and photograph the wear pattern. Take the alignment reading. Confirm which valve is actually installed. Find out whether the drawing matches the machine.
Scoped in hours, not days. No parts committed. One fact moved from unknown to known.
Most plants already do this work. They do it at three in the morning with the line down and a crew standing by, which is the same task performed at the worst possible time and the highest possible cost. Put a tape on it before the order goes in, and it is a ten-minute job.
Human authority boundaries
AI identifies gaps. Qualified people approve work.
The system may never move a dimension from Unknown to Known on its own inference. Only a named person with the relevant ticket can do that, and their name stays attached to the record.
This section is short and it is not negotiable, and it is the section that makes the whole framework acceptable to a safety manager. A plant that cannot say who signed cannot investigate its own incidents.
Where AI actually helps
The strongest first use is not autonomous job release. It is exception detection.
A readiness agent can read a backlog export, a work package, a shutdown scope or a CMMS record and identify missing fields, contradictions, stale evidence, unsupported assumptions, unclear completion criteria, and resource conflicts. It then generates the questions a planner or requester has to answer before the job advances.
Notice what that is. It is not diagnosis. It is not deciding what the job is. It is producing a list of things nobody looked at, which is precisely the category that took a month out of our chain day.
It is also a good commercial wedge, because it does not require replacing the CMMS. A first version works from CSV exports. A later version connects read-only. Only after trust is established should it draft corrections, and only after that should it write anything back.
Implementation path
Spreadsheet or CMMS export first. Integration later, and possibly never.
A readiness review run on an exported .csv and a checklist will find eighty percent of what a full integration would find, at no capital cost, in week one. I am aware that saying so costs me a hypothetical software sale. It is still true, and a reader who tries the cheap version and finds something is worth more than one who buys a platform and resents it.
Measuring something whose success looks like nothing
Every measure of a working readiness programme is a reduction in visible failure. Fewer schedule breaks. Fewer emergency purchases. Fewer discovery delays. Fewer aborted jobs. Fewer field clarification requests.
All five are absences, which is the hardest thing in the world to defend in a budget meeting, and it is the honest reason good planning is chronically underfunded. The man who recovers a line at three in the morning has an artifact. The man who stopped the job last Tuesday has nothing to point at.
So do not try to measure prevented failures. Count caught ones. Jobs stopped before release and the gate that stopped them. Discovery tasks raised and closed. Assumptions carried into the field and named. Parts kits found incomplete before the crew mobilized.
Each of those is generated as a byproduct of doing the work, and none of them requires claiming a counterfactual.
Conclusion
Industrial AI is lowering the cost of producing proposed work. It is not lowering the cost of determining whether that work deserves to be executed, and those two costs were never the same thing.
The Maintenance Readiness Review separates evidence, execution, operational conditions and authority, and it refuses to average them. Its central principle is that the faster a system can turn information into action, the more deliberately the organization has to verify readiness before action becomes real.
None of this is new. Every good tradesman already runs a version of it in his head, which is why the reliability matrix we paid consultants for turned out to be the thing I was already doing, written down. The value is not in the insight. It is in getting it out of one man's head and onto a page, where it can be checked by somebody else, applied by somebody less experienced, and still be there after he leaves.
Because he will leave. And the camelback chains will still need changing.
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
- IBM, “Working smarter with agentic workflows in Maximo Assistant,” Aug. 12, 2026. https://www.ibm.com/think/perspectives/working-smarter-agentic-workflows-maximo-assistant
- IBM Docs, “Creating custom AI tools in Maximo by using object structures.” https://www.ibm.com/docs/en/masv-and-l/cd?topic=tools-by-using-object-structures
- Oracle, “AI Agent: Maintenance Work Order Builder.” https://docs.oracle.com/en/cloud/saas/readiness/scm/25d/maint25d/25D-maintenance-wn-f40777.htm
- 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