Sensor replaced, Machine restarted: the four words quietly erasing your plant’s memory
Maintenance know-how is leaving factories faster than it is being written down. The problem is not only fixing the fault; it is keeping what the team learned while fixing it.
A control panel lights up at 3 a.m.
A line is down, a young technician is alone in front of a machine he has serviced twice in his life, and the one person who really knew this equipment retired last spring. He fixes it, eventually. Then he closes the work order with four words that will haunt the plant for years: “sensor replaced, machine restarted.” The line runs again. The knowledge of what actually happened is already gone.
Versions of this scene are familiar across industrial maintenance: the repair succeeds, and the reasoning behind it rarely reaches the next shift. Maintenance teams are ageing, turnover is rising, and the know-how that lives in a few experienced heads is walking out faster than it is being written down. “When the day shift arrives, they sometimes restart the whole diagnosis from scratch, because nobody quite trusts what was written about the night intervention,” says a maintenance manager at a large French electronics plant. It is tempting to read this as a staffing problem, something for recruitment and training budgets. It is more than that. It is a reliability problem. Every undocumented intervention is a small hole in the plant’s memory, and the holes compound: the same fault diagnosed from scratch three times, the mean time to repair creeping up, not because the team got worse, but because it keeps relearning what it already knew.
Artificial intelligence is now offered as the obvious cure, and that is exactly where things get complicated, because the two most common answers fall short in ways that matter on the shop floor. The first is the documentation assistant: a language model over the PDF manuals, whether it retrieves by keywords or by semantic search. Ask a question, get a fluent, confident answer. Fluent, confident, and shallow. A manual does not know that this valve is wired to that relay, or that a temperature alarm on this motor is, on this particular line, almost always a sensor fault rather than an overheating one. Even the best retrieval gives you sentences. It does not give you the machine.
The second answer is predictive maintenance, and the objection has to be precise, because the field is broad. Condition monitoring, vibration analysis, anomaly detection and physics-based models all have their place, and they answer a different question: whether a component is drifting towards failure, not why this machine is faulting now. The structural problem lies with the supervised variant, a model trained on the history of labelled failures so it can forecast the next one. Good maintenance teams stop machines before they break; that is precisely the mark of a mature operation. So the history contains few run-to-failure examples, and such a model learns from partial anomalies and threshold alarms, not from the events it is supposed to anticipate. The better the team, the thinner the data.
So what does useful AI look like on a real fault? Take one. A motor trips on a high-temperature alarm, but when the technician gets there, the motor is cold. The assistant has already read the machine’s electrical schematics, not as PDF pages but as a functional map: every component extracted, every connection traced, so it can follow how a fault in one place may produce a symptom somewhere else.
It states the expected behaviour, the technician confirms it, and the leading hypothesis comes back: an intermittent fault in the PTC temperature-sensing chain, with the component reference and the relevant sheet number in the schematic. First a visual inspection: nothing abnormal is found, and the result is recorded. Then a measurement on the probe, cold. The young technician admits he is not sure how to run the test. The assistant explains: ohmmeter, machine stopped, circuit disconnected, and which terminals to put the leads on, because the terminal numbers were extracted from the schematic too. The reading turns unstable the moment the cable is moved. By testing the sensor separately from its cabling, the technician isolates the intermittent fault to the PTC probe itself. The probe is replaced, the machine is restarted and normal operation is verified. The intervention report is then generated from the recorded steps: symptom, hypotheses, tests, readings, cause, remedy, and the residual risk to keep an eye on.
Another plant ran the approach retrospectively. A diagnosis that had taken a team four hours was replayed through the system: the faulty component surfaced after about ten minutes of dialogue.
Isolation, repair, verification and restart would still have taken their normal time. What shrank was the path from the first symptom to the first useful test.
Notice what the AI did and did not do. It did not announce “replace part X” like an oracle. It proposed, the technician disposed, and a human kept the final call at every step. The technician can push back, “it cannot be that, I already tested it”, and the system revises the hypothesis set accordingly. That distinction is not cosmetic; it is the line between a tool a maintenance crew will trust and one it will quietly abandon. And it rests on guardrails worth naming. Explainability: every suggestion traces back to its source, a schematic reference, a manual section, a past intervention, so the technician sees why, not just what. Traceability: a complete log of what the system did and what the human decided. Read against the European Union’s AI Act, these are not bureaucratic boxes to tick. Where a system falls within a regulated category, the requirements around documentation, logging and human oversight carry real weight. And even where they are not legally mandated, the same disciplines are what let a plant explain, months later, how a given decision was reached.
It is worth being just as honest about the limits. The approach depends on machine-specific evidence: an undocumented machine the system has never seen gives it nothing to reason over.
Schematic extraction is not error-free, so the functional map still requires human review before it is trusted. And the technology removes the blank-page problem and the memory loss; it does not remove the need for technical judgement. A technician still has to recognise an implausible hypothesis, run the test correctly and interpret what comes back. Poor judgement does not become sound judgement because an AI system sits alongside it.
Three questions before using ai for fault diagnosis
1. What evidence is the diagnosis based on? Retrieved text, machine topology, past interventions, sensor data, or several of these combined? The answer sets the boundary of what the system can reason about, and what stays outside it.
2. What does the available data actually contain? Any approach that learns from past failures depends on how many confirmed failure events exist and how representative they are. On a well-run site, that number is usually smaller than expected: fifty thousand work orders are not fifty thousand usable diagnoses.
3. What can the technician inspect and overrule? Every recommendation should trace back to a source that can be checked, and the operator should keep the final call on the maintenance decision.
Visible reasoning and a working override matter on the shop floor, and they matter again wherever the EU AI Act applies.
The real prize sits one level above the single repair. When interventions are captured properly, structured along the diagnostic path rather than scribbled as one-liners, they stop being static records and become a working memory. One plant discovered it this way: a variable-speed drive failed, was replaced, failed again, was replaced again. Read together and structured, the interventions told another story. The drive was a victim. The recurring cause sat one step upstream, in the fieldbus communication, a cable shielding and routing problem that no single work order, read alone, could reveal. Less experienced technicians can work through faults using the accumulated evidence, instead of waiting years to inherit an expert’s intuition. It works in the other direction too: a senior can record the trick nobody else knows, that on this machine, before re-teaching a robot point, you first check the reference positions, and the system resurfaces it the next time anyone, on any shift, reports a positioning fault. The know-how stops being trapped in one head. Each fault solved becomes an antibody against the next one. The factory, slowly, starts to remember.
From four words to a working memory
What a structured intervention record should capture:
• The symptom as observed, not just the alarm code: “high-temperature alarm, motor cold.”
• The hypotheses tested and ruled out, and why, so the next person skips the dead ends.
• The tests and the readings: which terminals, what value, what it did when the cable moved.
• The immediate cause (what restarted the machine) kept distinct from the root cause (what will stop it failing again).
• The remedy, the residual risks, the recommended follow-up.
Four words tell you a sensor was replaced. This tells you what your plant learned.
The caution behind that manager’s observation is justified. Maintenance teams should not be expected to hand diagnostic decisions to a black box. The useful question is therefore not whether to accept or refuse AI, but what evidence the system uses, what the technician can verify and contradict, and what remains in the plant’s records once the repair is done. If the reasoning disappears when the work order closes, the knowledge problem is still there in the morning.
Text: Text: Cédric Jean
ABOUT THE AUTHOR
Cédric Jean is the CEO and co-founder of Mimorian (https://mimorian.co), a French company building trustworthy AI for industrial maintenance. He works with industrial plants on capturing field know-how and supporting technicians’ reasoning, with humans keeping the final say, in line with the EU AI Act.
Subscribe to the free Maintworld newsletter here!
Latest
