Consulting for Pipeline Integrity Programs: API 1163 and 1160 Compliance Review

Why ILI Data Is Only as Good as the Qualification Behind It

A smart pig can run a flawless inline inspection and still leave a pipeline operator exposed if nobody validated that the tool actually finds and sizes what it claims to find and size, on that specific pipeline, in that specific product, at that specific run speed. That validation gap is precisely what API 1163, "In-line Inspection Systems Qualification," exists to close. It doesn't certify a tool once for all conditions — it defines a qualification process an operator has to run through for the specific application, and it's the piece of a pipeline integrity program most likely to be treated as a formality rather than as the load-bearing document it actually is.

API 1163 doesn't operate in isolation. It sits inside the broader framework of API 1160, "Managing System Integrity for Hazardous Liquid Pipelines," which defines what a complete integrity management program looks like — risk assessment, threat identification, data integration, and repair criteria — with ILI as one input among several. A pipeline integrity consulting review has to look at both documents together, because a technically sound ILI qualification file sitting inside a threadbare integrity management program is still a program with a hole in it.

The two documents also fail independently in different ways, which is part of why a review has to treat them as one exercise rather than two separate checklists. An operator can have an immaculate API 1163 qualification file — a well-built Performance Specification, a defensible validation plan, a properly stratified dig program — and still have an API 1160 program that never actually uses any of it to update risk rankings or reprioritize the next assessment interval. The reverse is just as common: a mature-looking integrity management program with a formal risk model and a documented threat matrix, resting on ILI data nobody ever independently validated against field conditions. Either failure mode produces a program that looks complete on a binder shelf and falls apart the moment a regulator asks to trace one specific anomaly from the ILI report through to the repair decision.

What API 1163 Actually Requires of an ILI Program

API 1163 structures ILI qualification around a Performance Specification — a document, usually built jointly by the operator and the ILI vendor, that states what the tool is expected to detect, identify, and size on the specific pipeline segment being run, under the conditions that segment presents: product type, wall thickness range, diameter, and expected anomaly types. The qualification process then requires that performance be validated in the field, not just asserted on paper.

Tool Qualification and the Performance Specification

A defensible ILI qualification file typically includes the Performance Specification itself, documentation of the tool's prior track record on comparable pipelines with similar diameter and wall thickness range, and — critically — a validation plan describing how the vendor's claimed performance will be checked against real dig data once the tool has actually run. An operator that accepts a vendor's published specification sheet at face value and skips this step has satisfied the paperwork but not the intent of API 1163.

Vintage pipe adds a qualification wrinkle that catches operators off guard. A segment built decades ago on electric resistance welded (ERW) pipe carries a threat profile — long-seam anomalies, hook cracks, hard spots near the seam — that a generic metal-loss tool qualified for corrosion detection was never designed to find. An ILI qualification file that doesn't explicitly address whether the selected tool technology is appropriate for the seam type and vintage of the specific segment being run isn't really qualified for that segment, even if the same tool has a strong track record on newer, seamless pipe elsewhere in the system. This is one of the more consequential findings a compliance review can surface, because it points to a threat category the operator's ILI program may not be covering at all, not just a documentation gap.

POD, POI, and Sizing Accuracy — What the Numbers Actually Mean

Vendors typically publish three categories of performance claims for a metal-loss or crack-detection tool: probability of detection (POD), the likelihood the tool flags a feature that's actually there; probability of identification (POI), the likelihood it correctly classifies what kind of feature it is — external corrosion versus a dent versus a manufacturing anomaly, for example; and sizing accuracy, typically expressed as a tolerance band with an associated confidence level for depth, length, and width. These numbers vary meaningfully by tool technology — magnetic flux leakage (MFL), ultrasonic (UT), and electromagnetic acoustic transducer (EMAT) tools each carry different strengths depending on whether the threat is metal loss, cracking, or geometry — and by pipeline-specific conditions like wall thickness variation and internal coating. The point of API 1163 qualification isn't to memorize the vendor's number; it's to confirm that number holds up on this pipeline, not just on the pipelines the vendor used to build its spec sheet in the first place.

Where API 1163 Meets API 1160: Integrity Management, Not Just Inspection

API 1160 lays out the structural elements of a hazardous liquid pipeline integrity management program: risk assessment, integrity assessment methods (ILI, hydrostatic testing, and direct assessment among them), data integration, repair criteria, prevention and mitigation measures, and performance measurement. ILI results from an API 1163-qualified tool run feed directly into several of these elements — but only if the data integration step actually happens.

Threat Identification and Data Integration

A common design flaw in immature integrity management programs is treating ILI as the entire threat assessment rather than one input into it. API 1160 expects an operator to consider the full range of threat categories relevant to hazardous liquid pipelines — external and internal corrosion, mechanical damage from third-party excavation, stress corrosion cracking, and manufacturing or construction defects among them — and to integrate ILI findings with cathodic protection survey data, coating condition history, and as-built construction records rather than reviewing ILI results as a standalone report.

Dig Verification Programs and Unity Checks

Once an ILI run identifies anomalies, the operator excavates a sample of them to physically verify the tool's calls — this is the dig verification program, and it's where API 1163's qualification claims get tested against reality. A statistically sound dig program stratifies its excavation sample across anomaly types and severities rather than digging only the largest, most obvious calls, and builds a unity chart comparing ILI-reported depth against field-measured depth — often confirmed by UT wall thickness readings taken at the dig site — across that sample. An operator that digs five convenient anomalies and calls the tool "validated" hasn't actually validated anything, and that's one of the most common findings a compliance review turns up.

The dig verification program also has to hold up statistically, not just visually. A unity chart with a handful of points clustered near the origin looks reassuring on a slide but doesn't demonstrate anything about how the tool performs on the anomalies that actually matter — the deeper, more severe calls where a sizing error has the most consequence. A properly built verification program deliberately includes digs across the full range of reported severities, documents the field measurement method used at each dig (UT thickness gauging at multiple points around the anomaly, not a single spot reading), and records enough digs per anomaly category to say something statistically meaningful about that category's actual POD and sizing accuracy on this pipeline — rather than borrowing the vendor's aggregate performance claim and assuming it applies uniformly.

PHMSA and 49 CFR 195 — the Regulatory Backdrop

For hazardous liquid pipelines, PHMSA enforces integrity management requirements under 49 CFR Part 195, with §195.452 specifically requiring an integrity management program for pipeline segments that could affect a high consequence area (HCA) — populated areas, commercially navigable waterways, and other drinking water or ecologically sensitive areas as defined in the regulation. PHMSA's framework leans heavily on the structure API 1160 describes, and PHMSA inspectors reviewing an operator's integrity management program expect to see the same elements: documented risk assessment, a defensible ILI qualification and validation trail per API 1163, an actual dig verification program with statistical grounding, and a change-of-condition process that updates the risk assessment when new information — a failed dig verification, a newly identified threat, a changed operating pressure — comes in.

A PHMSA inspection is not the moment to discover that the ILI qualification file consists of a vendor brochure and an email chain. Operators that treat the qualification and validation documentation as a living file, built and updated as each ILI run and dig program closes out, walk into a PHMSA review in a fundamentally different position than operators trying to reconstruct that history after the fact.

Common Gaps a Pipeline Integrity Compliance Review Finds

• ILI vendor performance claims — POD, POI, sizing tolerance — accepted from the spec sheet without an operator-side validation plan tied to actual dig data from that specific pipeline.
• Dig verification programs large enough in raw count to look credible but not statistically stratified — heavily weighted toward the largest, easiest-to-confirm anomalies rather than a representative sample across severity and anomaly type.
• Threat identification limited to corrosion mechanisms, with mechanical damage, stress corrosion cracking, and manufacturing or construction threats acknowledged in the program document but never actually assessed against pipeline-specific history.
• ILI data sitting in a standalone report rather than integrated with cathodic protection survey history, coating condition assessments, and as-built records — meaning the integrity assessment technically exists but doesn't inform risk ranking the way API 1160 intends.
• Repair criteria referenced generically without a clear, documented method — modified B31G, RSTRENG, or an API 579 fitness-for-service assessment — for translating an ILI-reported anomaly into an actual repair or re-inspection decision.
• No formal management-of-change process to update the integrity assessment when a dig verification contradicts the ILI call, or when operating conditions shift.
• ILI qualification files that don't address whether the selected tool technology is appropriate for the seam type, vintage, and known threat history of the specific segment being run — as opposed to relying on the tool's general track record elsewhere in the system.
• Performance measures tracked for regulatory reporting purposes but never actually fed back into the risk model that decides reassessment intervals — turning API 1160's continuous-improvement intent into a static, once-a-year paperwork exercise.

Gulf Coast Corridor Realities

The Gulf Coast pipeline corridor — running through the refining and petrochemical complexes around Houston and Beaumont-Port Arthur, and feeding into major hazardous liquid infrastructure like the Louisiana Offshore Oil Port — presents its own version of these challenges: dense pipeline crossings, a mix of vintage and modern pipe within the same system, and HCA density around populated Gulf Coast metro areas that raises the regulatory stakes on getting threat identification right. Operators running ILI programs through this corridor are also more likely to be running multiple tool technologies across a single system as it ages, which makes consistent qualification documentation across vendors and tool types — rather than a fresh, ad hoc qualification file every time a new vendor is brought in — a genuine operational advantage rather than a paperwork nicety.

What an Atlantis Consulting Engagement Covers

An Atlantis ASNT Level III consulting engagement on pipeline integrity typically starts with a document review — the integrity management program itself, the ILI qualification and Performance Specification files, and the dig verification history — followed by a gap analysis against both API 1163 and API 1160 side by side, since a finding in one document usually has a corresponding gap in the other. From there, the engagement builds a prioritized remediation plan: which gaps are PHMSA-exposure critical, which are simply best-practice improvements, and what sequence closes the most risk fastest.

Where PHMSA exposure is the concern, that remediation plan often includes a mock audit — walking the integrity management program the way a PHMSA inspector would, starting from a single anomaly in an ILI report and tracing it forward through the dig verification record, the repair or re-inspection decision, and the corresponding update to the risk model, to confirm the chain actually holds together end to end rather than existing as disconnected documents that happen to reference the same pipeline segment.

A recurring piece of that remediation work is structural, not just procedural. Dig verification data, ILI qualification records, and repair decisions scattered across vendor portals, spreadsheets, and email threads make it nearly impossible to build the kind of longitudinal unity analysis PHMSA and API 1163 both expect. Centralizing that data — including UT wall thickness readings taken at dig sites, formatted through NDT reporting software built for field verification work — and tracking calibration, personnel, and inspection records inside Atlantis NDT ERP turns a reactive, audit-triggered scramble into a program an operator can actually stand behind on request. For systems where visualizing anomaly history against the physical asset matters — comparing successive ILI runs, dig locations, and repair history spatially along a corridor — a digital twin platform gives an integrity team a single visual layer instead of a stack of disconnected reports.

Building an Integrity Management Program That Holds Up Under Review

API 1163 and API 1160 aren't independent hoops — they're two halves of the same argument, that a pipeline operator actually understands the condition of its asset because it can show its work, from tool qualification through dig verification through documented repair decisions. A program built that way survives a PHMSA audit as a matter of course. A program built by accumulating vendor deliverables without ever stepping back to check whether they add up to a defensible integrity case usually finds out the hard way that they didn't.

If it's been a while since your ILI qualification files and dig verification program were reviewed end to end against API 1163 and API 1160 together, that gap is exactly what a compliance review is built to close.

Atlantis NDT Products & Services

Atlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable — book a free consultation.