API 510 is usually discussed as an inspection interval problem: internals, externals, and thickness surveys on a clock derived from corrosion rate and remaining life. In practice, the harder obligation is the record. When a jurisdiction or an owner-user audit asks how an interval was set, the answer has to be reconstructable from documents, not memory.
The record the code expects
Strip the code language away and the recordkeeping asks reduce to a short list:
- Thickness history per CML. Not per vessel: per condition monitoring location, with dates, so a corrosion rate can be defended point by point.
- The basis for the interval. Half remaining life or the code maximum, whichever governs, with the remaining-life calculation traceable to the readings that produced it.
- Inspector qualification and sign-off. Who performed and who reviewed, with certifications current at the time of the record, not at the time of the audit.
- Repairs and alterations. What was done, under what procedure, with the post-work inspection attached to the same equipment record.
None of this is exotic. What makes it fail in the field is fragmentation: readings in one spreadsheet, reports in PDFs, certs in an HR system, and repair history in the CMMS. Each file is fine; the thread between them is what the auditor actually asks for.
Where programs lose the thread
The common failure is re-keying. A technician records a thickness reading on paper or a gauge, someone types it into a spreadsheet, someone else copies the minimum into a report. Every hop is a chance for the CML identity to drift, and once readings stop mapping cleanly to locations, corrosion rates stop being defensible.
The second failure is report-time assembly. If the inspection record is built weeks after the fieldwork, the evidence that should anchor it, photos, gauge readouts, and signatures, gets attached from memory. An interval decision that reads well can still be unsupported underneath.
What good looks like
A defensible API 510 program treats the record as something that assembles during the work: the reading lands against the right CML at capture time, the photo and the signature attach to the same record, and the remaining-life math runs from the stored history rather than a copy of it. The audit answer then already exists on the day the question is asked.
That is the operating model intelliSPEC is built around. If you want to see it against one of your own vessels, bring a CML history to a demo and walk the thread end to end.
