The Error Code Is Only the Symptom: Fault Reports as the Memory of the Plant

It is just after three in the morning, night shift. The filler FL-200 stops, and the display shows error E-217. The maintenance technician who has known the machine for years is on holiday. The colleague on call tonight joined only a few months ago. He knows this error has happened before. He just does not know when, at which station, or what helped back then.

This scenario is a thought experiment, and so is every machine, report and number in this article: filler FL-200, error E-217 and the service reports SB-0871 and SB-0914 come from fictional sample documents, not from a customer case. The situation itself is familiar to every maintenance team, though. The answer is somewhere in the building, in reports, tickets and manuals, just not where you can find it at night.

Our position: fault reports are the memory of a machine, but only if you find them through cause and action rather than through the error code. An error code is a symptom, and the same symptom can have different causes. A good tool therefore does not look for “the solution” but for the earlier cases, separates them by cause and shows where each statement comes from. What happens at the machine afterwards is the technician’s decision.

What a Fault Report Records

Every maintenance team writes reports, because it has to and because it wants to. The report documents the intervention, justifies the downtime and, at best, helps the next person. Whether it does so later depends on a handful of fields. The following table orders them by what they are needed for in a later search.

The first three rows describe what stood out. The last five explain what helped. When writing, it is exactly the other way round: whoever types a report at three in the morning enters the code first, because the form asks for it, and skips the justification of the cause, because their mind is already on the next job. That is human and not a reproach. It does explain why many plants have reports that are filed completely but hard to use.

Enlarge

There is also a filing problem. Reports sit as PDFs on a drive, as tickets in a tool, as entries in a shift book and as emails in the mailbox of whoever wrote them. Anyone searching would need to know four places and use four search screens. Memory that only works with local knowledge is really the memory of individual people. That is exactly the experience that leaves the building when they retire or move on.

One Code, Two Causes: The E-217 Example

Suppose the archive of our sample plant holds two service reports for error E-217 on filler FL-200. Both are fictional, both carry the same code, and both end with a resolved fault. Anyone who searches only for “E-217” finds both and still has no answer.

Both reports are about the same message, but they tell two different stories. In the first case the machine was fine and the pressure was set wrong. In the second case the compressed air was fine and a wear part had reached its end. Had the colleague read only the most recent report that night, he would, depending on luck, have been on the right track or the wrong one. In the bad case he would have replaced eight seal sets and used up 3.5 hours of downtime, although a glance at the pressure gauge would have done.

Enlarge

That is the core of the idea. The code says what the controller noticed. Suppose that in our fictional example E-217 means that a dosing station does not report its end position in time. It does not say why. An end position can be missing because too little air arrives, because a seal sticks or because a switch has shifted. These reasons can only be told apart by measuring and looking, and that measuring and looking is what, when written carefully, stands in the reports.

The second report holds one more useful piece of information that appears in no fault list: the service interval was shortened to 1,200 hours because the seal had swollen at 1,500 operating hours. That is lived experience. Whoever knows it can prevent the fault at the next service. Whoever does not know it services by the old rule and finds the seal swollen again.

Why Searching for the Code Alone Is Not Enough

Anyone who searches reports by code runs into three difficulties. All three can be spotted without software, but are easier to fix with it.

First, a search for the code returns hits without an order. Two or ten reports appear as a list, and each has to be opened and read one by one. That costs time at night, and it tempts people to stop at the first plausible report.

Second, the same fact is written in different words. One report says “pressure regulator misadjusted”, another “control air too low”, a third “check air supply at station 6, then OK”. A plain keyword search finds only what stands in the text verbatim. A search that compares meaning also finds the paraphrase.

Third, reports are not equally reliable. A report with readings and reasoning carries more than one that says “fault fixed”. A report from the identical station carries more than one from a similar machine. A report from three years ago carries less if the machine has been rebuilt since. This weighing is expert knowledge and cannot be delegated to a tool, but it can be supplied with information: date, project, station and evidence must be visible.

From these difficulties follows what a tool should deliver. It has to find the cases even when the words do not match. It has to sort them by cause instead of returning a flat list of hits. And it has to name the source for every statement, so that the technician can open and check the report personally.

From Code to Cases: How an Assistant Helps

An assistant with access to your documents can take on these three tasks. The following figure shows the path from the question to the decision.

Enlarge

The question. You ask it the way you would ask an experienced colleague: “Filler FL-200 reports error E-217. Has this happened before and what helped?” In the TheroAI demo this question exists as an example for plant engineering, with fictional documents. In our example the assistant answers that the error is documented twice, with different causes and actions, and returns a small table of the reports. At the end it gives the recommendation from the first report: check the control air pressure first, then the seals. For every statement it shows the passage as a numbered source.

The finding. The assistant searches only what the asking person is allowed to see. That is not a side issue: reports from other sites, personnel matters in shift books or confidential customer projects should not surface through the back door of a search. Sources are connected through connectors. With the Google Drive connector, document permissions are indexed along with the content, so the answer respects the rights of the person asking. Whether your own maintenance system can be connected is something to clarify case by case. Reports as documents in a collection also work without such a connection.

The sorting. This is where an assistant differs from a hit list. It reads the reports, recognises that two cases share a code yet have different causes, and sets them side by side. The table from the previous section is exactly what you would expect: report, cause, action, each with a source reference.

The sources. Every line of the answer leads back to the report. That is the precondition for the technician to trust the answer or contradict it. In maintenance, an answer without a source is an assertion, and you do not repair a machine with assertions. You can also set which sources the assistant answers from, for example only company knowledge and not the internet.

Anyone who asks recurring questions does not have to phrase them anew each time. The TheroAI library holds prompt templates, including one called “Störung nachschlagen” (look up a fault) in the maintenance category.

Enlarge

You can read more about how search, sources and answers work together on the page about the assistant. How this can be used in manufacturing and plant engineering is described on our pages for manufacturing and plant engineering.

The Order of Checks

With two causes behind one code, the question is where to start. The first report in our example gives a hint: its recommendation was to check the control air pressure first and then the seals. That is not arbitrary but follows a rule that carries over to many faults.

Which check is cheapest, fastest and least invasive, and can it rule out one of the possible causes?

Check first what costs little. A glance at the pressure gauge takes minutes, removing seals takes hours. If both causes are equally likely, the cheap check wins. If they are not equally likely, the more frequent cause moves forward, but even then it holds that a cheap check that reliably rules out one cause is rarely wrong.

An example calculation shows how large the difference can be. The numbers are deliberately round and explicitly assumptions, not readings from a plant.

Worked through: if you start with the pressure, the cause is found after 0.5 hours in the first case. In the second case the pressure check costs 0.5 hours and the following seal check 2 hours, together 2.5 hours. The average is (0.5 + 2.5) divided by 2, so 1.5 hours. If you start with the seal, it is 2 plus 0.5, so 2.5 hours in the first case, 2 hours in the second and 2.25 hours on average. The difference is 0.75 hours, or 45 minutes per fault, even though both orders end up finding the same cause.

Enlarge

Two caveats belong here. First, the assumptions are freely chosen. In your plant the seal may be reachable in ten minutes, or the pressure test point may be hard to get to. Then the calculation tips, and that is fine: the value of the example lies in the method, not in the number. Second, the order does not replace safety. Before anyone works on a pressurised station, the operating instructions of your company on isolation apply, however cheap the check looks on paper.

The order is, by the way, itself a piece of memory. If a report says “check control air pressure first, then seals”, that is condensed experience from an earlier job. An assistant that takes such recommendations from the reports passes them on together with the source and does not turn them into its own claim.

What Makes Reports Findable

A tool can only find as much as the reports contain. The good news: the levers are small and cost seconds when writing. Six habits are enough to begin with.

• Write cause and symptom separately: first what was visible, then what the cause was
• Name a reading that proves the cause, for example “4.8 bar instead of 6 bar”
• State station, assembly and part number so that the case belongs to the right configuration
• Describe the action so that someone else can repeat it, with the setting and the part
• Record downtime in hours so that you can later compare what a case costs
• Note what changes permanently, such as a shortened interval or a new warning threshold

The difference between a useful and a useless report can be shown in a few lines.

An assistant can also help with writing. It can turn keywords into a report draft and ask specifically about missing fields: “Which reading proves the cause?” The draft belongs in the hands of the person who carried out the intervention. They correct it, they confirm it, they are responsible for the content. If a report is to be passed on to customers or into another system, the path should include an approval by a person. How this is set up in TheroAI with workflows and approval steps is described on the page about workflows.

Limits: The Decision Stays with the Technician

Up to here much of this may have sounded like a shortcut. That is why a clear word on limits belongs here. An assistant prepares. It does not decide about an intervention on a machine.

Enlarge

Two cases are a hint, not proof. In our example there are two reports with two causes. That does not say there are only these two causes, and it does not say which is more frequent. A third cause remains possible, such as a faulty limit switch. Anyone who builds statistics from two reports over-interprets them.

The old case may no longer fit. Machines are rebuilt, controllers updated, manuals revised. A report from 2025 describes the machine as it was then. Whether variant, machine state and manual edition still match today can only be judged by someone who knows the machine. An assistant can show date and project, but it does not know what has been rebuilt since if that is written nowhere.

A report can be wrong. Even good specialists err, write under time pressure or mix up stations. An assistant that quotes correctly will then quote the error correctly. That is why the source reference matters: it makes the error checkable.

Permissions apply here too. Not everyone may see every report. The assistant should show only what the asking person could also see in the source system. That is a matter of setup that you should check before the start. Data is stored in Germany and AI processing takes place in the EU; details on data and access are on the page about security.

Reports name people. In many plants the report states who carried out the intervention. As soon as a system makes such information analysable, it may be suitable for monitoring performance or behaviour. Under German works constitution law this can require co-determination, see section 87 (1) no. 6 of the Betriebsverfassungsgesetz on technical devices intended to monitor the behaviour or performance of employees. This is not legal advice. Clarify the individual case with your legal counsel and involve the works council early, ideally with the commitment that the purpose is to find causes again and not to assess people.

The intervention itself stays human. Whether a station is isolated, a part replaced or the machine kept running depends on safety, responsibility and experience. An answer from the assistant should never become a work order that nobody checks any more. Where a system can carry out actions, TheroAI lets you set tools to allow, ask or block for each tool. For write access to systems close to production, “ask” or “block” is the sensible setting.

How to Start in Maintenance

Anyone who wants to tackle this does not need a big plan. A start that can be judged within a few weeks looks like this.

1. 1.Choose one machine or machine group where knowledge is at risk of being lost, for example because only a few people know it well.
2. 2.Collect the existing reports, tickets and manual extracts for that machine in one place, and clarify who may read them.
3. 3.Take five to ten closed faults whose cause you know for certain, and ask the assistant the question as if you did not know the answer.
4. 4.Compare the answer with what you know: was the right case found, were different causes separated, do the sources match?
5. 5.Note where the assistant missed, and ask whether it was the question, the reports or the search.
6. 6.Only then let colleagues ask in daily operation, with the clear note that the sources are to be checked.

This test with known cases is worth more than any demonstration. It shows how well your reports carry, and it shows it on cases whose outcome you know. If you want numbers, count for yourself: how often was the right case among the hits, and how often did someone have to ask a colleague? If you want to calculate the benefit, use your own values and not the example values of this article.

What You Can Take Away

The key points in brief: the code is the symptom. The same message can have different causes. The memory of the machine is in the reports, but only in those that name cause and action cleanly. A tool should find cases, sort them by cause and show sources. The cheapest and fastest check comes first, as long as it is safe. And the decision on the intervention stays with the technician.

Questions to ask in your maintenance team:

Do our reports state the cause separately from the symptom, with a reading that proves it?

Would a new colleague at night find the earlier cases for an error code within ten minutes, without calling a particular person?

For every answer, do we see which report it comes from, with date, project and station?

Do we know whether the old case still fits today’s machine, or does the technician have to check that first?

Is it settled who may see which reports and who talks to the works council before the start?

Which cheap check comes first for our most frequent fault, and is it written in the report?

Concrete steps for the next few days:

1. 1.Read three of your latest fault reports and mark whether cause, reading and action are recognisable separately.
2. 2.Define five closed faults as test cases, with the known cause as an answer key.
3. 3.Decide which sources should be accessible for the test, and who may see them.
4. 4.Agree with maintenance that every suggestion is checked against its source and never implemented blindly.

If you would like to see what such an answer with sources looks like, you can take a look at the demo, in your own time and with your own questions.