The same code on different machines: building a useful report
An analyst collects messages from different devices and finds many entries with the same code. Grouping them under one label looks convenient, but it can combine entirely different meanings. The report needs to account for the machine each message came from. A lookup table can assign known codes to categories. An AI model is worth testing for free-text descriptions and abbreviations the table does not recognize.
Syntalith
Why E17 alone is not enough
This fictional example compares equipment families A and B. The code meanings are also invented for the example. Family A’s documentation defines E17 as a communication-related message. In family B, the same code concerns a temperature sensor.
Putting every E17 entry into one group would hide that difference. A useful report separates communication messages from family A and temperature-sensor messages from family B. The analyst can open the original records, see the equipment involved, and check the documentation used to assign the category.
If a record contains only E17 and its equipment family cannot be identified, it remains unresolved. One meaning appearing more often in the archive does not justify assigning it to this entry. The missing context must come from the source or equipment register.
A known meaning can come from a lookup table
When the equipment family and code meaning are established, an ordinary lookup table is enough to assign a category. In the example, family A combined with E17 always leads to the communication message specified in its documentation. Training a model to reproduce that mapping would add work without solving a new problem.
Before commissioning a model, check which information reaches the report. An export may omit the equipment name, or different systems may use different names for the same family. Resolving those links lets the report use the known code meanings. If the documentation distinguishes equipment versions, that information needs to remain available too.
The person responsible for documentation confirms which meanings can share a reporting category. This work classifies message content. The category alone does not establish a physical cause, urgency, or instructions for handling the equipment.
Where a model can help
Not every system supplies a readable code in a separate field. Information may appear in descriptions, abbreviations, or messages from successive equipment generations. When the source equipment is known, a model can help assign those expressions to agreed reporting categories.
This differs from a lookup. The model needs to recognize which known meaning the text refers to even when its wording differs from the report’s label. Equipment context is still necessary. Adaptation does not supply the missing family for an isolated E17 entry.
Start with an existing model given clear categories and the appropriate context. Google describes supervised tuning for defined tasks, including classification. It also explains that a general model may be sufficient when instructions produce consistent results. Further training becomes worth testing when recurring errors remain that the team can identify.
Fine-tuning means training an existing model further on correctly assessed examples. It can be used to help recognize these varied descriptions. The team contributes knowledge of the documentation and corrections to wrong assignments. A new code meaning in another equipment family must first be established from sources before it becomes part of the report.
Is the result useful for a shared review?
Assess the trial on messages and equipment families not used during adaptation, with the relevant documentation and equipment context available. The analyst checks which assignments need correction and how many entries still need clarification. Compare the result with a lookup table and an existing model wherever each method applies.
The analyst needs the number of incorrect assignments alongside the number left unresolved. Both represent remaining work, but a wrong category also requires correcting a part of the report that appeared complete.
If your task instead involves organizing technicians’ notes about observations and work performed, see our article on fine-tuning for maintenance event reporting.
One report across different equipment systems
Syntalith proposes a custom reporting application that connects messages with equipment information and produces a shared report while retaining the original records. The analyst sees the category, its supporting reference, and entries that need clarification. After making corrections, they can use the report during the team’s review.
We start with the connections between equipment, documentation, and messages. Your team confirms meanings and identifies past misassignments. We establish which mappings a lookup table can handle and compare an existing model with adaptation for varied descriptions. The scope also includes bringing the result into the place where the team prepares its report today.
Describe one code or message that currently groups different issues together. Tell us where the records come from and who can check their meaning. That is enough to begin discussing scope; engagement information is on Syntalith’s pricing page.
Match a model to the task you need it to perform
Describe where your current AI falls short. We will compare model customization options, data requirements and the cost of running the resulting system.
Private LLMs and fine-tuning