Inspection Records That Survive a Ten-Year Audit and a System Migration

The unit of storage is the equipment item

Inspection data gets filed the way it gets sold. A purchase order arrives, a job folder is created, technicians drop reports into it, and the folder closes when the invoice goes out. That structure is perfectly aligned to commercial reality and perfectly misaligned to every technical question anyone will ask later. Nobody has ever asked an inspection contractor to produce everything filed under purchase order 4500219877. They ask for everything ever recorded on a vessel.

The equipment item is the only entity in the system that outlives everything else. Technicians move on, contracts expire, software is replaced, site naming conventions change hands twice a decade. The vessel stays, with the same tag, for forty years. Building the hierarchy on the longest-lived entity is not a stylistic preference; it is the only choice that survives the timescales the record has to cover.

The practical form is simple. Asset register at the top, equipment item beneath it, condition monitoring locations beneath that, and every reading, report, repair and calculation hung off the item or the location. Job number, purchase order, crew and technician all become attributes on the record rather than levels in the tree. Everything a commercial system needs remains queryable; nothing depends on it structurally.

OSHA already specified your record fields

There is no need to invent a schema for a US site under process safety management. 29 CFR 1910.119(j)(4)(iv) states that the documentation shall identify the date of the inspection or test, the name of the person who performed it, the serial number or other identifier of the equipment on which it was performed, a description of the inspection or test performed, and the results. Five fields, written into federal regulation in 1992, still unimproved.

Read that list structurally and it settles the argument in this article. One of the five is an identifier for a physical thing that persists. The rest are properties of an event. The regulation is describing a record keyed to equipment, with the technician as a field on that record rather than a folder above it. Systems that invert this are fighting the rule they are trying to satisfy.

The frequency rule sits alongside it in 1910.119(j)(3): inspection and test frequency shall be consistent with applicable manufacturers' recommendations and good engineering practices, and more frequently if determined necessary by prior operating experience. Prior operating experience is a data question. A system that cannot produce the history of an item cannot justify its own interval, which is the argument set out at /consulting/osha-psm-mechanical-integrity-ndt.

Report numbering that cannot collide

Report number collisions are the most common structural defect in inspection data, and they are always discovered at the worst possible moment, which is halfway through a client audit. The causes are consistent across every firm that hits them: sequential counters that reset each January, per-technician numbering that duplicates across crews, per-site counters that collide the moment two sites are merged under one register, and spreadsheet-generated numbers that repeat every time a file is copied as a template for the next job.

The fix is a composite key with no shared counter. Site code, method, equipment identifier, date and a per-asset sequence produce a number that is unique by construction and readable by a human. It also encodes what the report is about, which means a filename remains meaningful after it has been emailed twice, printed once and scanned back into a client document management system with the metadata stripped.

Never reuse a number, even for a cancelled report. A cancelled examination is part of the record: something was mobilised, something prevented it, and that fact belongs in the history. Mark the record void with a reason and leave the number spent. Auditors read gaps as concealment, and a spent number with a reason attached is the cheapest possible answer to that question.

Revision control: supersede, never overwrite

Inspection reports get revised. A thickness reading is transcribed wrongly, a drawing reference is corrected, a client rejects a format, an engineer requires an added calculation. Each of those is legitimate. What is not legitimate is the corrected file replacing the original in place, because the original was issued, was relied upon, and may already have supported a fitness-for-service decision.

Every revision needs four things: a revision identifier, a date, the name of the person who authorised it, and the reason. That final field is the one systems omit and auditors always ask for. Revision 2 with no stated reason invites the question of what was wrong with revision 1, and the absence of an answer is far more damaging than the original error would have been.

Superseded revisions stay retrievable for the same period as the current one. Where a revision changes a measured value rather than a presentation detail, it should trigger the management-of-change discipline described in 1910.119(l), because a changed thickness changes a corrosion rate, which changes an interval, which changes a plan. Document control practice for the governing procedures is set out at /blog/document-control-for-ndt-procedures-and-written-practices.

Retention is set by the regime, not by the inspection code

Firms routinely look to API 510, 570 or 653 for a retention period and find nothing, then default to seven years because that is what the accountant said. API settled the question directly: asked how long API Std 653 requires inspection records to be retained, the published interpretation replies that API Std 653 does not specify the retention period. The code requires the file to exist and be complete; it never sets a clock.

The clock comes from the operating regime. On PSM-covered process equipment, OSHA's 1996 interpretation is unambiguous that mechanical integrity documentation under 1910.119(j)(4)(iv) must be kept for the lifetime of the process. Incident investigation reports run five years under 1910.119(m)(7). Only the two most recent compliance audit reports must be retained under 1910.119(o)(5). Under EPA SPCC, 40 CFR 112.7(e) requires signed inspection and test records held with the Plan for three years.

Where one asset falls under several regimes, the longest period governs the entire record rather than a subset of fields. A tank inside a PSM-covered process and inside an SPCC Plan is not a three-year record with a lifetime annex; it is a lifetime record. Encode the rule per asset class in the system so retention is computed rather than remembered, and the gap assessment at /consulting/ndt-program-audit-gap-assessment stops finding the same finding every year.

Personnel and calibration records are inspection records

A thickness reading is only defensible when two other facts were true on the day it was taken: the examiner held a current certification for the method and level, and the instrument held a current calibration. Auditors reconstruct exactly that triangle, and firms that store the three facts in three unconnected places spend days rebuilding it for each request while the client waits.

Certification records need effective and expiry dates, method, level, the written practice they were issued under, and the eye examination date. Instrument records need the calibration date, the next due date, the standard used and its traceability. Both need to be joinable to a report by date, which means the report must record which instrument and which examiner, not just a name typed into a header field.

This is the mechanical reason certification tracking at /erp/ndt-personnel-certification-tracking and calibration management at /erp/ndt-equipment-calibration-tracking-software belong on the same platform as the reports rather than in two separate spreadsheets maintained by two separate people. The evidence pack builds itself when the joins already exist. Better still, the same joins work preventively: a system that knows both facts can refuse to issue a report against a lapsed certification or an out-of-calibration instrument, which turns a compliance finding into a validation error nobody outside the office ever sees.

The migration problem, and why PDFs are not an archive

Every inspection firm changes systems eventually, and every migration loses something. The losses follow a pattern. Structured readings stay behind in the old database while their rendered PDFs come across, so the trend data is gone even though the reports look intact. Superseded revisions are dropped as duplicates by an import routine that deduplicates on filename. Asset identifiers are renumbered because the new system enforces its own format.

A PDF is a rendering, not a record. It cannot be queried for a corrosion rate, cannot be joined to a certification, and cannot be recomputed when a nominal thickness is corrected. An archive of ten thousand PDFs is an archive of ten thousand images of data. The structured layer beneath them is the actual asset, and it is the layer that has to be exported, validated and re-imported.

Test a migration by reconstruction rather than by count. Pick fifteen assets across methods and years, and rebuild each full history in the new system: readings, revisions, certifications, calibrations, repairs. If all fifteen reconstruct, migrate. If any fails, the mapping is wrong and running the full load will bury the defect under volume. The practical route out of spreadsheets is set out at /blog/replacing-spreadsheets-in-an-inspection-business.

The CML register is the spine

Condition monitoring locations are where the per-asset principle stops being an argument and becomes concrete. A CML identifier is a physical claim: this point, on this component, at this orientation and this elevation. Every reading taken there across decades is comparable only because the identifier means the same thing each time, so an identifier that quietly shifts meaning between campaigns corrupts every corrosion rate computed from it, every remaining life calculation built on that rate, and every interval justified by that calculation.

Stability requires three commitments. Identifiers are never reused when a component is replaced; the old location is retired and a new one created with a documented relationship to it. Positions are surveyed once and reused rather than re-established by memory each campaign. Changes to the register are versioned with reasons, exactly like report revisions, because a moved CML is a changed measurement basis.

Get the register right and everything downstream starts working at once: trend plots that mean something, remaining life figures an engineer will sign, interval calculations that survive the kind of challenge described at /blog/proving-rbi-inspection-intervals-to-a-regulator, and readings that can later be bound to spatial geometry without a reconciliation project. The construction detail sits at /blog/building-a-cml-register-that-survives-ten-years. Of every data structuring decision an inspection organisation makes, this one returns the most, and it costs almost nothing to get right at the start.

Build the evidence pack before the auditor asks

The test of an inspection data structure is not how it looks in a demo. It is how long it takes to answer a cold request: produce the complete inspection history for these six items, with the certifications and calibrations that applied on each date, every revision with its reason, and the interval calculation with its basis. Firms with per-asset structure answer in an afternoon. Firms with per-job structure answer in a fortnight, incompletely.

Run that request against yourself once a quarter, on assets chosen at random rather than on the ones already known to be clean. The exercise surfaces exactly the defects that matter: identifier drift, missing revision reasons, certifications that expired mid-campaign, readings with no instrument recorded. Each is cheap to fix while the technician who took the reading is still employed and expensive to fix afterwards.

Atlantis builds this structure into the inspection platform described at /ndt-inspection-software and the operational back end at /erp, with one equipment-keyed spine running from field capture through certification and calibration checks to invoicing at /erp/ndt-software-quickbooks-integration. The reporting shortlist at /best-ndt-reporting-software-2026 applies the same test to other tools. Affordable, accessible and fully customisable, configured to the specific regimes a site sits under, with a demo or a scoped quote available on request through /contact.

Request a consultation