Picture this. A machine stops. A technician checks a few things, identifies the problem and gets it running again. The ticket says: “Fault cleared. Equipment operational.”
Production restarts. The ticket can be closed.
But based on that record, will the next shift know what to check when the symptom comes back?
This is where I would start any conversation about AI in maintenance.
What caught my attention in the Rockwell case
In an article by Dennis Scimeca published in IndustryWeek on 24 September 2026, Rockwell Automation reports that at its plant in Singapore the mean time to repair (MTTR) fell from 18 to 12 minutes. The AI assistant described there draws on process data, fault history, manuals for 394 machines and knowledge written down together with the technicians. Source: IndustryWeek.
This is a company claim quoted in the publication. The article offers no independent verification and does not specify the periods compared. I treat the result as a starting point for questions about your own process, not as a promise for every plant.
What interests me most here is the knowledge the technicians documented. What follows is my own proposal for how to approach a pilot — not a description of Rockwell’s implementation.
01 Record the knowledge the next shift will use
On its own, “sensor replaced” would not be enough for me. I would want to know which symptom led the technician to that particular component. What did they check first? Which suspicions did they rule out? What test confirmed that the problem was gone?
In my proposal, the event record would answer six questions:
- What happened? The symptom, the alarm and the impact on the machine’s operation.
- Under what conditions? Product variant, settings, cycle phase and recent changes.
- What was checked? The order of the checks and their results.
- What was established? A confirmed cause — or a hypothesis that still needs checking.
- What was done? The specific action and the parts used.
- How was the result verified? A test after the repair and later observation of whether the symptom returned.
I would not expect an essay after every stoppage. I would start with a short form for a selected group of faults. I would judge its quality with a simple test: can another technician follow the diagnostic reasoning without phoning the author?
02 Link every AI suggestion to a source
In a first pilot, I would expect help finding verified information. The technician describes the symptom, and the system points to similar events, the relevant documentation and the actions taken before.
Every suggestion should lead to a specific source: a ticket, an approved instruction or a confirmed note. I would also want to see which machine and configuration a given record applies to.
Where information is missing, I would expect a clear message that there is no basis for an answer. I would treat an AI suggestion as material to be assessed by an authorised technician, in line with the applicable safety procedures.
AI could also prepare a draft summary of the repair. The technician would review and approve it. I would label the hypothesis, the action taken and the confirmed cause separately. That way I would aim to reduce the risk that a guess from one ticket starts to function as a ready-made answer at the next breakdown.
03 Find out at which stage you are saving time
I would want to establish in which part of breakdown handling the improvement appears. That is why I would record separately the time of the report, the start of diagnosis, the identification of the cause, the completion of the repair and the release of the machine back to production.
I would also agree separately on the definition of MTTR and of total downtime. I would not assume the plant calculates them the same way. Earlier diagnosis, faster repair and earlier release to production are three different results, and I want to be able to tell them apart.
On top of that I would add the waiting time for parts or support, and whether the same fault recurred within an agreed period.
Before comparing results, I would agree on a common definition of when the measurement starts and ends. I would compare similar types of faults and show the number of events in both groups. I would also check whether staffing, parts availability or the scope of inspections changed at the same time. Without that, I would not attribute the whole difference to the AI assistant.
04 Run a pilot and decide based on the results
I would choose one group of machines and a recurring problem for which we have documentation and people who can judge whether the suggestions are correct.
First, I would go through earlier tickets with the technicians, fill the gaps where they can be reliably reconstructed, and name the person responsible for approving and updating the knowledge.
Next, I would test the system on known cases. Does it find the right information? Does it point to sources? Can it admit that similar symptoms are not enough to establish the cause?
Only then would I start using it on live tickets. Before the start, I would agree with the team what results would justify continuing. I would assess diagnosis time, the usefulness of the answers, the number of wrong suggestions and the effort needed to maintain the knowledge base.
05 Go back to the cause at the shift meeting
At the shift meeting, I would be interested in more than the fact that the machine is running again. I would also ask: what did we learn about the cause? What will we change to reduce the chance of a repeat? Who will check the effect, and when?
That is how I would want to use LEAI — the combination of Lean and AI: making knowledge easier to access, then using it to check causes and improve the process.
Before buying an AI assistant, I would run one simple test. I would pick a few recent repairs and ask a technician from another shift to explain, based on the records alone, what happened and why a given action was taken.
Wherever we have to fill in the story from memory, that is where I would start work on the knowledge base.
At a joint review, I would pick one ticket and check the six fields of the repair record. Then I would name an owner for the missing information and a deadline for filling it in. A task like this is a good place to start preparing for a pilot.
- Dennis Scimeca, “Rockwell’s Singapore Lighthouse Plant Heavily Leverages AI” — IndustryWeek, 24 Sep 2026 — source of the Rockwell Automation data.
- Commentary, questions and the pilot proposal: the makeXcellence perspective. They are not a description of procedures used by Rockwell.