A search engine over technical documentation finds the documents that discuss a topic. Diagnosis asks for something else: knowing how the components of a machine depend on one another, so you can trace a symptom back to its cause. The two services look alike in a demo and separate clearly in front of a breakdown.
The distinction shows up among manufacturers who have already taken the step. Some have built their own document assistant, plugged into their technical libraries, and are still looking for an extra building block for maintenance. Industrial intelligence platforms such as Mimorian model equipment as a functional graph and structure diagnosis from that map, rather than from documents alone. This article explains where the boundary lies.
What does a document assistant do, and where does it stop?
A document assistant indexes a corpus, understands a question in natural language and returns the relevant passages. For finding a procedure, a part reference or a parameter value, it delivers real value and saves time.
Its limit appears as soon as the question concerns a specific machine in a specific state. "The conveyor stops intermittently after restart" has no answer in a document, because the answer depends on the actual wiring, on successive modifications and on what has already been observed on that piece of equipment.
The assistant then returns the documents that contain the words of the question. The technician receives reading material, where they expected a ranked hypothesis.
A second blind spot matters just as much: documentation describes the machine as it was delivered. After fifteen years of retrofits, it describes equipment that no longer quite exists.
What does a functional model change?
A functional model describes the links between components: what feeds what, what controls what, what trips when another element fails. It is built from electrical, pneumatic and hydraulic drawings, not from manuals.
| Technician's question | Document assistant | Functional model |
|---|---|---|
| Where can I find the replacement procedure? | Answers directly | Answers as well |
| What torque value should I apply? | Answers directly | Answers as well |
| Why does this fault appear only when hot? | Returns documents to read | Traces the chain of possible causes |
| Which components should I test first? | No ranked answer | Ranks them by the structure of the machine |
| Has this fault been seen elsewhere? | Depends on what was written down | Cross-checks against intervention history |
The first two rows explain why a document assistant satisfies at the start. The next three explain why it plateaus.
The gap widens further on rare faults, the ones where experience counts most, and where documentation is precisely at its most silent.
Should you replace an existing document assistant?
No, and this is the point that is often misunderstood. The two layers complement each other: document search remains the right tool for retrieving written information, the functional model takes over for reasoning about a machine.
A manufacturer who has already invested in an assistant keeps a useful asset: the corpus is gathered, access rights are set, teams have got into the habit of querying a tool. What is missing sits underneath, in how the equipment itself is represented.
The order in which you add it matters: model the critical equipment first, the machines whose downtime costs the most, rather than aiming at the whole plant. Our comparison between ChatGPT and orchestrated AI in maintenance sets out this difference in kind, and our article on the hidden time spent searching for information shows what search alone leaves on the table.
The cost of what stays out of reach can be measured: inefficient knowledge sharing costs a large business an average of $47 million per year [Source: Panopto, 2018]. Part of that loss survives the roll-out of a search engine, because it concerns knowledge that was never written down.
Frequently asked questions
Can a document assistant diagnose faults with the right configuration?
It can return a diagnosis that has already been written down somewhere. It cannot build a new one on a machine whose structure it does not know, because the necessary information is missing from its corpus.
Do drawings need to be up to date to build a functional model?
Usable drawings are enough to start, and the discrepancies noticed during interventions then correct the representation. An imperfect model that corrects itself beats frozen documentation.
How many machines need modelling before the benefit shows?
Critical equipment first. The benefit shows from the first faults on those machines, without waiting for full plant coverage.
What happens to the existing document assistant?
It carries on serving searches for written information. The two layers answer different questions and coexist without conflict.
Conclusion
Three points to remember.
- Searching for a document and diagnosing a fault are two distinct tasks. The first works on a corpus, the second on the structure of a machine.
- Documentation describes the original machine. After years of modifications, the functional model sits closer to reality than the manual does.
- The two layers complement each other. A document assistant already in place remains an asset; what is missing sits underneath.
Next step: take the three most recent faults that took the longest, and check whether the answer existed somewhere in the documentation.