# Searching old service reports is a data problem, not a model problem

Old service reports are hard to search because of what's in them: abbreviations, typos, mixed languages, scans with no text and uncaptioned photos. A 30-report audit shows which problems your archive has, with a practical fix for each, starting with new reports.

**Short answer:** Old service reports are hard to search because of what is in them, not because the search tool is weak. Free text, abbreviations, mixed languages, fault codes written several ways, scans with no text layer and photos with no caption all hide a fix from any tool. Audit 30 reports first, then fix what the audit finds, starting with new reports.

**Applies to:** service and maintenance teams with years of service reports, job cards or work orders in PDFs, shared drives, email or paper. **Last verified:** 4 Nov 2026. **Author:** Muhammed Fahiz

## What does an old service report look like to a search tool?

Here is a real maintenance work order, quoted as it appears in a 2021 paper by researchers at NIST, the University of Western Australia and GE Digital:

> Hyd leak at saw atachment. Hydromat Saw 012, hydpump not working; rep with new HS012

Any service engineer can read that. The pump on saw 012 wasn't working, there was a hydraulic leak, and the part was replaced. The authors ran this kind of text through a standard, off-the-shelf language-processing pipeline to show what goes wrong:

- The step that splits text into words doesn't split "hydpump", because two words were run together.
- The standard stop-word list removed "not". The meaning flipped from "the pump was not working" to "the pump was working".
- The cleaning step stripped numbers, and with them the asset number HS012.
- The steps that reduce words to a common form didn't merge "hyd", "hydraulic" and the misspelled "hydaulic".

None of those failures came from a weak model. Each one came from the text: an abbreviation, a typo, two words run together, an asset number in a field meant for words. The paper's summary of maintenance records in general is blunt: typical work-order data contains "messy, unstructured raw text" and "inconsistent, incomplete, incorrect, or missing codes and data formats".

Łukasz Kincel made the same point in a LinkedIn post in October 2026. Most of his post was about two new open-weight models for running search and simple yes/no decisions on the device itself, offline. His advice to service leaders before a pilot ended like this: "The model is the easy part. The hard part is your repair history: free-text reports, mixed languages, photos without context. Search can only be as good as what it searches."

That's the subject of this post: what in an old report stops search from working, how to check your own archive, and what to do about each problem.

![Workbench beside a CNC lathe covered with loose service report sheets, an open ring binder, a clipboard, a phone and two uncaptioned photos of machine parts](/blog/media/searching-service-reports-data-problem-mw1myysw.png)

## Is it a model problem or a data problem?

Mostly a data problem, though the two overlap. A vendor account on X (@polsia, promoting its own maintenance copilot) put it the other way round in August 2026: "Most plant downtime isn't caused by missing data. It's caused by missing retrieval". That's true when the answer is written down clearly and nobody can reach it in time. It stops being true when the answer was never written in a form any tool can match.

A better model helps with some of the problems below and not at all with others:

| Problem in the archive | Example | Does a better model fix it? | What fixes it |
|---|---|---|---|
| Abbreviations, typos, run-together words | hyd, hydaulic, hydpump | Partly. Meaning-based matching can link some variants. Exact codes and asset numbers still need exact matching | A shared term list, used in search and in new reports |
| Negation lost or never written | "pump not working" vs "pump working" | Only if the tool keeps the full text | Keep full text. Write the result plainly |
| Mixed languages | One fault, written in English by one engineer and in another language by the next | Only if the tool handles every language your team writes in. Test it on your own reports | A short line in your team's working language next to the engineer's own words |
| One fault code, several formats | SV0401, 401, "VRDY off" | Only if the variants are known | A "code as displayed" field and a variant list |
| Scans and photos of pages | Scanned job card, phone photo of a handwritten report | No. There is no text to search until OCR runs | OCR, then check it worked |
| Photos with no caption | A burnt board, sent in a chat with no message | Partly. Kincel notes newer models put text and images in one search space, "so a photo of the fault can find the report that describes it". That still needs a report that describes it | Keep the photo with its report and caption it |
| No machine identity | No model or serial number on the report | No | Model and serial as required fields |
| Drafts and duplicates | Three versions of the same visit | No. It finds all three | Search the finalized version only |
| Reports nobody can reach | Personal inboxes, chat groups, paper files | No | Decide where finalized reports live |

*Our summary. The abbreviation and negation examples come from the NIST paper. On why exact codes still need exact matching, see our post on [keyword search vs chat for fault-code lookup](https://hangersearch.com/blog/fault-code-lookup-keyword-search-vs-chat).*

Most rows end in the same place. A tool can only return what's in the text it can reach.

## How do you check whether your old reports are searchable?

Run a small audit before you change tools or templates. It takes an afternoon and gives you a list of problems in your own archive, not a general one.

1. **Pick 30 finalized reports at random.** Spread them across years, engineers and machine types. Don't pick the good ones.
2. **Score each report against the eight checks below.** Yes or no for each.
3. **Count the no's per check.** The checks with the most no's are where to start.
4. **Run five real searches.** Pick five faults your team fixed in the last year that someone still remembers. Search the archive the way a new engineer would: the code as displayed, then a few symptom words. For each one you don't find, note which check explains the miss.

| Check | How to test it | Why it matters for search |
|---|---|---|
| Text layer | Open the PDF and use Ctrl+F on a word you can see on the page | If it isn't found, the page is an image and nothing in it is searchable |
| Machine identity | Are the model and the serial number both on the report? | Without them you can't search one machine's history |
| Fault code as displayed | Is the exact code written, not "alarm came"? | The code is the most precise search term you have |
| Cause and fix | Does it say what was found and what was done, not just "ran OK after reset"? | A report you find but can't use is still a miss |
| Language | Which languages and scripts is it written in? | Tells you what your search has to handle |
| Photos | Are photos in the report or linked from it, with a caption naming the unit and the part? | An uncaptioned photo can't be found or trusted later |
| Final version | Is this the signed or final version, and is it the only one? | Drafts give conflicting answers |
| Location | Where did you find it: shared drive, email, chat, paper? | Search only covers places it can reach |

*Our suggested checks, not a standard.*

The five test searches matter more than the scores. They tell you, in your own reports, whether misses come from the words, the scans, or the places reports are kept.

## What can you do about each problem?

Start with whatever the audit flagged most. Each fix below works without retyping the archive.

### Free text and abbreviations

Build a term list from your own reports. Go through the audit sample and write down every abbreviation and spelling you find, with the full term: hyd and hydaulic for hydraulic, a drive's code next to its message text, your team's short names for machines. The NIST authors call this kind of list a data dictionary, which maps common terms to a standard meaning (their example: "Replace" = "Solution Action").

Use the list two ways: as extra search terms when you look for an old fix, and as the agreed spelling in new reports. If you want to go further, NIST publishes a free tool, Nestor, that helps maintainers tag work-order text exported as a CSV file (UTF-8).

Keep negations. "Not running at start" and "running" are one word apart, and a report has to say which.

### Mixed languages

Don't translate the archive. Translation is slow, and it loses the engineer's own words, which are often the most exact description of what was seen.

For new reports, add one short line in your team's working language next to the engineer's own text: the code as displayed, the symptom, the cause found and the fix. For old reports, do the same only for the machines that keep coming back. If your search tool claims to handle several languages, test it with real reports in each language your team writes in, including any that mix scripts.

The same problem turns up in OEM documents. As one technician put it on X: "Opening a machine wiring diagram at work with only german text i can't understand".

### Fault codes written in different formats

Add a field for the fault code exactly as displayed, then a lookup list of the other ways your team has written it. Our post on [finding a fix someone solved three years ago](https://hangersearch.com/blog/alarm-already-solved-three-years-ago) shows how one FANUC servo alarm turns up as SV0401, 401 and "VRDY off". If one machine's faults are described differently every time, our post on [why repeat faults never add up](https://hangersearch.com/blog/repeat-breakdown-same-machine) covers grouping records by machine before you count.

### Photos without context

Keep photos with the report they belong to, not only in a chat thread. Give each one a caption that names the machine (model and serial), the part, and whether it is before or after the fix. A consistent file name (serial, date, part) helps when the photo gets separated from the report anyway.

### Scans with no text layer

Run OCR on scanned reports, then repeat the Ctrl+F test on a few of them. OCR is not always on by default, and some services only process files uploaded after it was switched on. The SharePoint details are in [our earlier post](https://hangersearch.com/blog/alarm-already-solved-three-years-ago).

### Drafts, duplicates and scattered locations

Decide what counts as final (signed, sent to the customer, or approved) and where final reports live. Search that set. Drafts and personal copies only add conflicting answers.

![Steel shelving rack of identical ring binders with blank tabs, a flatbed scanner on a small table with a stack of report sheets, and an air compressor in the background](/blog/media/searching-service-reports-data-problem-mw1mzdg3.png)

## Should you clean up the whole archive first?

No. Fix forward, then fix backward only where it pays.

- **Fix forward.** Change the report template so new reports pass the audit: code as displayed, model and serial, cause and fix, captioned photos. Our post on [what to write before closing a breakdown job](https://hangersearch.com/blog/its-running-now-is-not-a-fix) lists six things a write-up needs.
- **Fix backward, selectively.** Run OCR on scans of the machines with the most repeat visits, and add one-line summaries to their most important old reports. Leave the rest as they are until a search needs them.
- **Measure again.** Repeat the five test searches after a few months.

## What this doesn't tell you

The NIST paper is a short position paper about maintenance work orders in maintenance management systems and language-processing pipelines. It isn't a test of service-report search, and its pipeline example is one illustrative work order. We found no study that measures how much each of these fixes improves search on service reports. Kincel's post is mainly about on-device models; we use only his framing. The 30-report audit is our suggestion, not a standard.

## Where does HangerSearch fit?

We built HangerSearch with this problem in mind. It's private, retrieval-only search over your team's own finalized service reports, searched where they already sit. You search by fault code, model or symptom. It shows the prior reports that match and why each matched, and opens the cited page. Nothing is generated, and if there's no similar report, it says so. It can't add a serial number or a cause that was never written down, which is why the audit comes first. See [how we handle your reports](https://hangersearch.com/trust).

Book a 20-minute demo: hangersearch.com

## FAQ

### How do I search old service reports?
Search by the fault code exactly as displayed, then by its other written forms, the machine's model and serial number, and a few symptom words. Check that scanned reports have a text layer (Ctrl+F on a visible word). Read the full report you find, and check it was the finalized version before you act on it.

### Why can't our search find old service reports?
Usually because of the reports, not the search. Common causes: scans with no text layer, abbreviations and typos, fault codes written in several formats, missing model or serial numbers, uncaptioned photos, and reports kept in inboxes or chat groups that search can't reach. A 30-report audit shows which ones apply to you.

### Will a better AI model fix messy maintenance records?
Only partly. Meaning-based search can link some variant spellings and wordings. It can't search a scan that has no text, find a serial number that was never written, or tell you what an uncaptioned photo shows. As Łukasz Kincel put it: "Search can only be as good as what it searches."

### Should we translate old service reports into one language?
Usually not. Translation is slow and can lose the engineer's exact description. Add a short line in your team's working language to new reports (code, symptom, cause, fix), do the same for old reports on machines that keep failing, and test your search on real reports in each language you use.

## Sources

1. Michael P. Brundage, Thurston Sexton, Melinda Hodkiewicz, Alden Dima, Sarah Lukens, "Technical language processing: Unlocking maintenance knowledge", Manufacturing Letters 27 (2021), pp. 42-46: https://doi.org/10.1016/j.mfglet.2020.11.001 (author manuscript on PMC: https://pmc.ncbi.nlm.nih.gov/articles/PMC13191364/). Read 4 Nov 2026. Supports: the example work order (Table 1, MWO C), the tokenization, stop-word, cleaning and stemming failures (section 2.1), the "messy, unstructured raw text" and "inconsistent, incomplete, incorrect, or missing codes" quotes (section 1), data dictionaries and the "Replace" = "Solution Action" example (section 3.2), Nestor listed as a resource (Table 2).
2. Łukasz Kincel, LinkedIn post, 9 Oct 2026: https://www.linkedin.com/posts/lukasz-kincel_your-technician-is-in-a-plant-basement-no-activity-7514242153645203456-ubdP. Reread 4 Nov 2026. Supports: the "model is the easy part" quote and the "one search space" quote.
3. Polsia (@polsia), post on X, 19 Aug 2026: https://x.com/polsia/status/2089892402337316965. Vendor post promoting its own product. Read 4 Nov 2026. Supports: the "missing retrieval" quote only.
4. @fiftycentis, post on X, 9 Oct 2026 (UTC): https://x.com/fiftycentis/status/2108643779930677597. Read 4 Nov 2026. Supports: the German wiring-diagram quote.
5. NIST, "Nestor" software page: https://www.nist.gov/services-resources/software/nestor. Read 4 Nov 2026. Supports: Nestor is a free toolkit for tagging maintenance work orders supplied as UTF-8 CSV files.