API 1163 — Qualifying an ILI System and Validating the Run

What API 1163 covers, and the three things it leaves to other standards

API 1163 is the qualification standard for an in-line inspection system taken as a whole: the tool and its sensors, the data acquisition, the analysis software, and the procedures and people that turn raw signals into a feature list. It is deliberately performance-based. It does not prefer magnetic flux leakage over ultrasonic, does not specify sensor pitch, and does not tell an operator when a line is due for inspection. What it insists on is that whatever system is offered has stated performance, that the performance is qualified with evidence, and that the delivered result is checked against reality.

Three things sit outside it, and the boundary is where most scoping errors happen. Personnel qualification belongs to ASNT ILI-PQ, which sets the levels and the certification requirements for data analysts and operating personnel. The field execution of the run itself, from cleaning and gauging through to launching, tracking and receiving, belongs to AMPP SP0102, formerly NACE SP0102. And the decision about what to do with a reported anomaly belongs to the regulations and to the remaining-strength methods, not to 1163.

There is a fourth omission worth naming, because it is the one that bites operators rather than vendors. API 1163 does not qualify a tool for your specific pipeline. Qualification is against a stated envelope, and the operator has to confirm that the line sits inside it: wall thickness range, minimum bend radius, bore restrictions, product, temperature, cleanliness and velocity. A tool qualified for a range your line falls outside of is an unqualified tool for that run, no matter how good the qualification report looks.

The performance specification: the numbers a vendor has to commit to

The performance specification is the operative output of the standard. It states what the system will detect, at what threshold, with what probability; what it will correctly identify as a class of feature; how accurately it will size in depth, length and width; and how accurately it will locate. Every one of those claims carries a certainty. For magnetic flux leakage inspecting general metal loss, a widely published specification is depth within 10% of wall thickness at 80% certainty, with a detection threshold in the region of 10% of wall thickness at 90% probability of detection.

The part most readers skip is that the specification is a table, not a line. Tolerances differ by anomaly class. General corrosion, pitting, axial grooving, axial slotting and circumferential grooving typically carry different depth bands, because the sensor response to a short deep feature is not the response to a broad shallow one. Features in or adjacent to a weld, in the heat-affected zone, or under a casing or coating disbondment, are commonly given wider tolerances or excluded outright. If your dominant threat is selective seam weld corrosion, the general metal loss row is not your specification.

Location accuracy deserves the same attention, because it drives dig success rather than assessment. A specification quoting distance from the nearest upstream girth weld within a few tenths of a metre, plus a clock position tolerance, sets what your excavation crew has to be able to find. Where location accuracy and dig practice are mismatched, you generate not-found excavations that get recorded as tool misses and quietly poison the validation dataset. Reconciling the dig record against the reported feature list is the sort of exercise that benefits from independent inspection report validation before the numbers get used to judge the tool.

System qualification is not the same as validating one tool run

API 1163 creates two distinct obligations that are constantly collapsed into one. System qualification asks whether this class of system, with this hardware, this firmware and this analysis methodology, performs as the specification claims. The evidence for it is accumulated over time: pull-rig tests, test loop runs on samples with known defects, and historical field comparison data. Run validation asks a narrower question: did this particular run, on this particular line, under the conditions it actually encountered, deliver results consistent with that specification.

A system can be properly qualified and a run can still be invalid. That happens when the line falls outside the qualified envelope, when the tool suffered sensor loss or data gaps, when speed excursions occurred, or when the pipe was dirty enough to lift sensors off the wall. The run report should carry the operating record that lets you check all of this, including the speed trace, sensor coverage and data quality summary. Where that record is absent, the validation argument has a hole in it that no number of digs will fill.

Change control is the third element and the one auditors reach for. A change to the analysis algorithm, a firmware revision, a new sensor configuration or a different analyst qualification route is a change to the qualified system, and it needs to be assessed against the qualification evidence rather than absorbed silently between runs. Operators who keep the vendor's qualification package, the software version and the analyst records alongside the run data in an inspection data management system can answer that question in minutes; operators who keep them in three unrelated places usually cannot answer it at all.

Verification levels and the evidence that supports each

The standard describes verification as escalating rather than binary. The lowest level is an internal consistency check: does the reported feature list reconcile with what is known about the pipeline? Girth weld counts, wall thickness transitions, valves, tees, casings, bends and previously recorded repairs should all appear where records say they are. A run that cannot reproduce the pipeline's own inventory has a systematic problem, and no dig programme will rescue it.

The next level compares reported features against a limited set of field measurements, and the highest level is a statistical comparison across a sample large enough to test the certainty claim. The comparison is usually drawn as reported depth against measured depth on a unity plot, with the specification band drawn around the diagonal. A specification claiming 80% certainty implies that roughly that proportion of comparison pairs should land inside the band. Systematic offset matters more than scatter: a tool that consistently undersizes is a different problem from one that scatters symmetrically.

The trap embedded in all of this is treating the field measurement as truth. A pit gauge reading has its own uncertainty, operator dependence and geometry limitations, and comparing an ILI number against it without stating that uncertainty produces a comparison nobody can defend. Laser profilometry or gridded ultrasonic measurement of the excavation, with the method and its uncertainty recorded, gives a far stronger dataset. When a validation fails, the response is not to bin the run but to constrain it: derate the tolerance, add targeted excavations, or re-analyse the data, and document why. That decision record is the deliverable an auditor asks for.

How API 1163 sits with ILI-PQ, SP0102 and 49 CFR

In the United States, operators using in-line inspection on gas transmission and hazardous liquid pipelines are directed by 49 CFR 192.493 and 195.591 to the in-line inspection standards incorporated by reference, which is where API 1163 acquires enforceable weight alongside ASNT ILI-PQ and AMPP SP0102. Read as a set they cover system, people and process. Read individually, each leaves a gap that an integrity management audit will find, because the auditor will ask for all three and accept a stack of one.

The incorporation-by-reference mechanism creates its own trap. Regulations incorporate a named edition, and standards get revised on their own cycle, so the newest published edition and the enforceable edition can differ for years. Procedures written against whichever version happened to be on the shelf will not match. The workable habit is to state the edition explicitly in your ILI procedure, check it against the incorporation list, and where the editions differ, satisfy the more onerous requirement rather than arguing about which one governs.

Downstream of the run, the standard hands off entirely. Whether a reported anomaly is an immediate, one-year or monitored condition comes from the regulations; remaining strength comes from ASME B31G, modified B31G or RSTRENG; and the programme logic for reassessment intervals comes from ASME B31.8S or API 1160. The bridge between the ILI feature list and those decisions is a mechanical integrity workflow that records assessments, timelines and closure, which is exactly what mechanical integrity software exists to hold.

Reporting, location accuracy and feature interaction

A conforming report is more than a spreadsheet of depths. It should carry feature class, dimensions in depth, length and width, location referenced to an identified upstream girth weld, clock position, the nominal and measured wall thickness at that location, the joint identifier, and enough of the tool's operating record to judge data quality. Without the joint reference and the reconciled weld count, the second run three years later cannot be aligned to the first, and corrosion growth rate becomes guesswork.

Feature interaction rules deserve a direct question to the vendor. Adjacent metal loss can be reported as several small features or boxed into one large cluster, and the choice changes the reported length and therefore the predicted failure pressure substantially. Different vendors apply different clustering rules, and a change of vendor between runs can produce apparent growth that is entirely an artefact of boxing. Ask which interaction rule was applied and hold it constant across the asset, or normalise before comparing.

Run-to-run comparison is where reporting discipline pays. Consistent alignment, a persistent feature identity and a stable interaction rule are what let you calculate growth rather than difference. Where a pipeline has been inspected by three vendors over a decade, the reconciliation work is substantial and it is worth doing once, properly, into a single feature record rather than repeatedly at each assessment cycle.

The misreadings that generate audit findings

The first is certainty. An 80% certainty statement describes the proportion of sizing calls expected inside a tolerance band, and it is repeatedly reported to management as though 80% of the corrosion had been found. Detection is a separate claim with a separate number, defined at a threshold depth. Conflating them produces integrity decisions built on a misunderstanding of what the tool ever promised to do.

The second is evidence substitution. A vendor datasheet is a claim; a qualification report with test data behind it is evidence. An audit that asks for the qualification basis and receives a brochure has found a finding. The same substitution happens with personnel, where a technician's radiographic or ultrasonic certification is offered in place of an ILI data analyst qualification under ASNT ILI-PQ. They are not interchangeable, and the analyst grading matters more to the result than most operators expect.

The third is unexamined dig results. Not-found excavations get logged as tool errors when the real cause was a location error, an excavation that did not expose the reported clock position, or a field method that could not resolve the feature. Undersized calls get pooled across anomaly classes so that a genuine pitting problem is hidden inside a general metal loss average. Cleaning that dataset before drawing conclusions is skilled work, and where an operator lacks in-house capacity it is normal to bring in ASNT Level III consulting to write the verification procedure and adjudicate the comparison.

Where the operator's responsibility begins

The obligation starts before tool selection, with a stated objective for the run. Which threat is being inspected for, which feature classes matter, what detection threshold is needed for the integrity decision that follows, and what sizing accuracy the assessment method requires. An operator who has not written that down cannot judge whether a vendor's specification is adequate, and will end up accepting whatever tolerance the proposal happens to offer.

Validation is the operator's responsibility and cannot be delegated to the party whose performance is being validated. The vendor's report is a deliverable; it becomes a validated result only after the operator has run the consistency checks, selected a defensible excavation sample, measured with a method whose uncertainty is stated, and documented the outcome including any derating applied. Auditors ask who signed the validation, and the answer needs to be someone on the operator's side of the contract.

Finally, keep the qualification package, run record, dig sheets and assessment decisions together as one auditable chain for the life of the asset. Reassessment intervals, growth rates and repair deferrals all rest on it, and reconstructing it five years later from email attachments is the sort of exercise that turns a routine audit into a finding.

Request a consultation