Legacy report archives: making twenty years searchable

Somewhere in every established plant is a room. It holds twenty years of inspection reports: contractor binders, signed PDFs on a shared drive, turnaround close-out packages, radiography envelopes. Every one of them was produced at real cost and signed by a qualified person. Almost none of them are ever read again, because reading them requires knowing which one to open. When a new indication appears on a nozzle and the engineer asks whether it was there in 2011, the answer is a two-day search or a shrug. Inspection report archive digitization is the work of making that room answer questions in minutes. Done well, it also makes the archive more defensible than the paper ever was.

Why is twenty years of reports worth less than it should be?

The reports are not worthless. They are unreachable, which for practical purposes is the same thing. The reasons are structural.

• They are filed by event, not by equipment. A turnaround package is filed by turnaround. A contractor report is filed by contract. The engineer's question is always about a piece of equipment, and nothing in the filing answers it.
• They are documents, not data. A thickness table on page 14 of a PDF is a picture of numbers. It cannot be queried, trended or compared without a person transcribing it.
• Their metadata is in the file name. tells you the year and the unit. It does not tell you which of the two hundred equipment items in Unit 3 it covers, or what was found.
• They have moved. Twenty years means at least two document systems, three shared drives and one office relocation. Some reports exist only on a departed contractor's server.
• Nobody owns them. The inspection function owns the current plan. The document control function owns the archive's storage. Nobody owns making the archive useful.

The result is that the plant keeps re-inspecting to answer questions the archive already answered, and cannot demonstrate to an auditor or a regulator that a historical inspection took place without a search that may or may not succeed.

Scan, index, or extract: what level of digitization do you need?

Digitization is not one activity. It has three levels, and each has a different cost and a different payoff. Choosing the level per report class is the central planning decision.

Scan. Convert paper and film to images and store them. This is the cheapest step and the least useful on its own. A folder of scanned PDFs is a filing cabinet that takes up less space. Scanning is necessary for preservation and for everything that follows, but a plant that stops here has not made the archive searchable.

Index. Attach structured metadata to every report: the equipment items it covers, the inspection type, the date, the contractor, the author, the standard applied, and a disposition summary. Store the report as an attachment on the equipment records it covers. This is where most of the value lives. Once indexed, the question "show me every internal inspection on V-101" is a query, and the report opens from the equipment record.

Extract. Transcribe the readings and findings inside a report into the structured history: thickness readings at CMLs with dates, findings as mechanism records with status, radiography interpretations as fields. This is the most expensive level, because numbers must be verified. It pays off only where the extracted data changes an engineering answer.

A practical policy:

• Scan everything that exists only on paper or film, before it degrades or is lost.
• Index every report, including those already digital. This is the step that should be complete for the whole archive.
• Extract from reports whose readings or findings are not already in the structured record, prioritized by equipment still in service and by mechanisms still active.

For most plants, indexing the whole archive and extracting from perhaps a fifth of it delivers nearly all of the benefit.

What metadata does every archived report need?

The index is only as good as its fields. A minimum set, each as a structured field rather than free text, so the archive can be filtered rather than read:

• Equipment covered. One or many, each as a reference to the equipment node in the hierarchy, not as a typed tag. A report covering forty items is attached to forty records.
• Component and CML coverage where the report is specific to them, so a CML's record can show every report that ever measured it.
• Inspection type. External visual, internal, on-stream thickness, radiography, ultrasonic, CUI, and so on, from a controlled list.
• Date of inspection (not date of report), because intervals are computed from when the equipment was examined.
• Contractor and author, and where available the author's qualification at the time.
• Standard or procedure applied, from a controlled list, with the edition where the report states it.
• Disposition summary. Acceptable, repair required, monitor, further examination, as a field.
• Original location and format. Where the paper is, or which system the file came from, so the original can be produced.
• Extraction status. Not extracted, partially extracted, fully extracted, with the date and person.

The temptation is to shortcut this with the file name and a keyword search. Resist it. Keyword search over OCR text finds reports that mention a tag; it does not distinguish the report that inspected V-101 from the one that mentioned it in passing on a piping isometric. Structured coverage does.

Indexing is the step that benefits most from being done inside the inspection system rather than in a separate document management system, because the fields above are references to equipment, components and CMLs that already exist there. In a document system they are text.

How do you extract CML readings from old PDFs without corrupting the history?

Extraction is where digitization can do damage. A reading transcribed against the wrong CML, or with a dropped digit, enters the history and changes a corrosion rate. Once a rate is wrong, an interval is wrong. The controls below are what keep extraction safe.

1. Extract into the same record the field would use. A 2011 thickness at CML 114 on E-2104 becomes a dated reading on that CML, with the same fields a technician would fill today: value, unit, date, technician if known, instrument if known, and a qualifier that marks it as extracted from an archive.
2. Attach the source page. Every extracted value carries a reference to the report and page it came from, and the report is attached to the record. A reviewer can open the page beside the number.
3. Verify every number by a second person. OCR and assisted transcription draft; a person confirms against the page. Thickness values in particular should never enter the history unverified.
4. Do not overwrite existing history. If the structured record already has a 2011 reading and the archive report disagrees, load the archive value with its source, flag the CML, and let an engineer decide. Silent reconciliation rewrites the past.
5. Preserve the report's own derived values separately. If the 2011 report states a corrosion rate, record it as the report's stated rate, not as the system's rate. The system recomputes from readings; the report's number is evidence of what was believed at the time.
6. Recompute and compare. After extraction, recompute short-term and long-term rates and remaining life on the affected CMLs and review any that moved materially. A large change is either a genuine discovery or an extraction error, and both deserve an engineer's attention.

Extraction of thickness tables from scanned pages is tedious work and the place where assisted tooling helps most. Tooling that locates the right report and drafts the transcription saves hours. The verification step is not optional regardless of how good the tooling is.

How does retrieval work once the archive is indexed?

An indexed archive supports two kinds of retrieval, and a program needs both.

Structured retrieval is filtering on the index fields. Every internal inspection on V-101. Every radiography report by a given contractor in 2015. Every report with a disposition of repair required on equipment still in service. These are queries, and they should be saved views in the inspection system.

Document retrieval answers questions the index does not anticipate. Which reports mention a particular nozzle. Whether any report described pitting on the bottom head before 2010. What the 2008 turnaround package said about the reformer inlet. This is where retrieval over the text of the archive earns its place, and where discipline matters most.

The rule for document retrieval is that every answer cites the source record. A response that says "the 2008 report noted pitting on the bottom head" is useful only if it links to the 2008 report and the passage, so the engineer can open it and read the context. Retrieval that summarizes without citing is a source of confident errors, because the summary cannot be checked and the archive's whole purpose is to be checkable.

The second rule is that retrieval reads only the tenant's own documents and records. An answer about V-101 must come from the plant's archive, not from general text about pressure vessels.

An archive that answers quickly but cannot show its source has not been digitized. It has been replaced with a rumour.

Spectra, the grounded AI layer in intelliSPEC, works this way: retrieval over the tenant's own documents and records, with every answer carrying a citation to the source record and collection. Vision analysis on photographs can also help classify and describe scanned images during indexing. Its actions that create or update records require approval by default, so retrieval never edits the history it reads.

What controls keep a digitized archive defensible?

An archive is evidence. Digitizing it must not weaken that status, and with the right controls it strengthens it.

• Immutable originals. The scanned image of a signed report is stored once and never edited. Annotations, if any, are separate layers on a copy. Encryption at rest protects the store.
• Attributable extraction. Every extracted value records who extracted it, who verified it, when, and from which page. Extraction is a data entry act like any other and is audited as such.
• Attributable access. Who read which report, when, from where. A hash-chained audit trail that records reads as well as writes, and that is never auto-deleted, gives an auditor a complete account.
• Attributable export. When a report leaves the system, the export is an audited event with an actor. This matters for archives that contain contractor-confidential or safety-sensitive material.
• Retention policy. A written decision about what happens to the paper and film after scanning: retained, or disposed of with a record of disposal. Regulators differ on whether a scan replaces an original; the policy should say what the plant's regulator accepts.
• Access control by hierarchy. Reports attached to equipment inherit the entitlement of the equipment node, so a contractor with access to one unit sees that unit's archive and nothing else.
• Pinned rendering. Any structured record built from the archive should render forever as it did when it was created, even after forms change, so the extracted history is as stable as the scan.

A program that meets these controls can show an auditor the scanned original, the extracted value, the person who verified it and the chain of custody in one view. That is more than the filing cabinet ever offered.

How intelliSPEC handles it

intelliSPEC treats archived reports as attachments on the equipment record rather than as files in a folder. A report is attached to the asset, component or CML nodes it covers in the hierarchy graph, with inspection type, date, author and disposition as fields on the record, so the index lives beside the equipment it describes. PDF and drawing annotation is available on the device, and drawings uploaded from the archive get automatic CML point detection, so an old isometric becomes a live map of the points it shows. Extracted readings land on the same CML records field crews use, which carry 64 fields including tMin and its method and three corrosion rates, and intelliINTEGRITY recomputes short-term, long-term and governing rates and remaining life so a newly extracted reading's effect on the interval is visible at once.

Every read, write, import and export is written to a per-tenant, hash-chained audit trail that carries actor, request identifier and device details and is never auto-deleted; a verify routine recomputes the chain for auditors. Data is encrypted at rest with AES-256 and access follows node-level entitlement over the hierarchy. Completed records pin their field configuration so extracted history renders as created. Retrieval over the archive runs through Spectra with citations to the source record on every answer. intelliCOMPLY holds the retention and procedure documents the archive policy refers to, and the Trust Center describes the controls, which are mapped to SOC 2 criteria, in detail.