Piping is where inspection programs carry the most equipment and the least documentation per item. A vessel has a name, a file, and a history. A piping circuit has hundreds of components, dozens of condition monitoring locations, and a record that often lives in three systems at once. API 570 is written with that reality in mind, and the audit questions it generates almost always land on the record.
The classification decision comes first
API 570 sorts piping into classes by consequence: what the fluid does if it escapes, and where it escapes to. The class drives inspection extent and interval, so the classification decision itself is part of the record. An auditor who sees a Class 3 interval applied to a line will ask why it is Class 3, and the answer needs a documented basis: service, location, and the reasoning that assigned it.
That basis has to survive service changes. When a line is repurposed, the classification, the damage mechanism review, and the interval all need revisiting, and the record should show that they were.
What the piping file must hold
Reduced to its working parts, a defensible API 570 file carries:
- CML identity and history. Each condition monitoring location with its readings, dates, and the component it sits on. Rates are computed per CML, not per line, so the identity has to hold across surveys.
- The interval basis. Half the remaining life or the class maximum, whichever governs, with the remaining-life calculation traceable to the readings behind it.
- Injection points and mixing points. These get treated as their own circuits with their own inspection scope, and the record should show they were identified and covered.
- Soil-to-air interfaces and dead legs. The known trouble spots. An auditor expects to see them listed, inspected, and dispositioned, not discovered.
- Inspector qualification and sign-off. Current at the time the record was made.
- Repairs, alterations, and rerates. Attached to the same circuit record, with post-work examination results.
Where piping records break
The first failure mode is CML drift. A location gets renamed between surveys, a drawing gets redlined without the database following, and suddenly two readings that should form a corrosion rate no longer map to the same point. The rate becomes an average of two different places, which is to say, not a rate.
The second is circuit-level bookkeeping for component-level questions. Auditors do not ask how a circuit is doing. They ask how a specific elbow downstream of an injection point is doing, and whether its interval reflects its own thinning rather than the circuit average.
The third is the orphaned repair. A clamp or a weld repair gets done under work-order pressure, documented in the maintenance system, and never joined to the inspection file. Years later the record shows a line thinner than its history explains, and nobody can say why.
The standard the record has to meet
The practical test is reconstruction. Pick a CML, and from the file alone, an outsider should be able to recover the reading history, the corrosion rate, the minimum required thickness, the remaining life, and the interval decision that followed, with names and dates on each step. If any link in that chain lives in someone's memory, the record is incomplete no matter how good the fieldwork was.
intelliSPEC builds the piping file this way by default: readings land against the right CML at capture, and the rate, remaining life, and interval trace back to stored history. Bring one of your circuits to a demo and walk the chain yourself.
