Pipeline Integrity Management Software: Making Two Vendors' ILI Runs Agree on the Same Anomaly

Why the second inline inspection run is where integrity programs break

An integrity engineer has a 2014 run from one tool vendor, a 2019 run from a second, and a 2024 run from a third because procurement went to market each time. The question the whole program exists to answer is whether a metal loss feature at a given location is growing. Answering it requires knowing that feature 3,412 in the 2019 report and feature 2,987 in the 2024 report are the same physical anomaly. The tools disagree about odometer distance, they reference different girth welds because some welds were not detected on one run, they size depth differently within their stated tolerances, and one vendor boxes clustered corrosion where the other reports individual pits.

So the alignment happens semi-manually. Someone matches on features near known reference points, works outward, and builds a crosswalk in a spreadsheet. On a long line that takes weeks, and the result carries an unstated confidence level. Every growth rate calculated downstream inherits that uncertainty, and every dig decision, reassessment interval and risk score is built on top of it.

The stakes are why this gets funded. Integrity management is federally mandated under the gas transmission and hazardous liquid rules, an incident is catastrophic and public, and inline inspection plus the dig program consumes a large recurring capital budget. An operator digging features that were not growing, while a genuinely growing feature sits unmatched between two runs, is spending capital and carrying risk at the same time.

Problem 1: alignment is the hard problem and most tools assume it is solved

New Century Software builds capable GIS-centric integrity data management, and if your spatial data already sits cleanly in the pipeline data model it expects, it is a serious option. The friction appears when your centreline carries station equations, re-routes, replaced segments and survey vintages that do not reconcile, which describes most operators who have grown by acquisition. ROSEN NEXUS and Baker Hughes platforms handle their own inspection data extremely well, which is precisely the structural issue: you need a neutral place to align a run from one vendor against a competitor's run from five years earlier, and a tool vendor's platform is not naturally that place. Dynamic Risk brings strong consulting-led risk modelling, but the algorithm sits with the consultant, so re-running it against new data is an engagement rather than a Tuesday.

A custom build makes alignment a first class, auditable process. Girth weld sequences are matched with a scoring approach that tolerates missed welds, odometer drift is corrected against fixed references such as valves, casings and known appurtenances, and every anomaly match carries a confidence value and the evidence that produced it. Low confidence matches are surfaced for engineering review rather than silently accepted. The result is that a growth rate comes with a statement of how sure the match is, which is what an engineer actually needs before recommending an excavation.

Problem 2: the centreline is a data quality problem wearing a map

Integrity decisions depend on pipe attributes: diameter, wall thickness, grade, seam type, vintage, coating, and whether the segment sits in a high consequence area. Those attributes came from records that are decades old, partially reconstructed, and in places genuinely unknown. Meanwhile class location and consequence area determinations change as development moves toward the right of way, which means a segment that was not in scope last year is in scope now.

Most systems store attributes as facts. They are not facts, they are assertions with varying provenance, and treating a reconstructed seam type with the same confidence as a mill test report is how an integrity program produces a risk ranking that engineers privately distrust.

A custom build carries attribute confidence explicitly: source, date, method and a confidence classification per attribute per segment. Then the risk model can treat an unknown seam type as the uncertainty it is rather than defaulting quietly, and a data validation program can be targeted at the segments where uncertainty actually changes a decision. Operators who do this find that a modest number of segments drive most of the uncertainty in their risk ranking, which turns a vague records improvement program into a short prioritised list.

Problem 3: the dig program and the closeout evidence are two different systems

A dig is planned in integrity, executed by construction or a contractor, inspected with non-destructive examination in the field, and closed out with a repair. The field measurements almost never match the inline inspection call exactly, and that difference is valuable information about tool performance that most operators never systematically capture. Meanwhile the regulatory clock on response conditions runs from the day the condition was discovered, and the evidence that the response happened within the window has to be assembled later from work orders, field reports and photographs.

Work management systems hold the work order. Integrity systems hold the anomaly. The excavation report is a PDF from a contractor. Nobody holds the object that connects the original call, the field verification, the remaining strength calculation, the repair method and the date the condition was resolved.

A custom build makes the dig a record spanning all of it, with the response clock computed from the discovery date and visible against the deadline. Field verification data feeds back into a tool performance record per vendor per run, so the next procurement conversation is grounded in how each vendor's calls actually compared against excavation, which is information operators have and almost never use.

What a custom integrity build has to include

• A vendor-neutral alignment engine matching runs to a single centreline, tolerant of missed girth welds, odometer drift and differing reporting conventions, with confidence stated per match.
• Anomaly matching across vintages producing growth rates that carry both measurement tolerance and match confidence.
• Pipe attribute storage with source, method, date and confidence per attribute rather than as bare values.
• Consequence area and class location as versioned determinations with effective dates, since they change and prior decisions must remain reproducible.
• Dig prioritisation using the operator's own criteria and risk algorithm, executable in-house against new data.
• A dig record spanning the original call, field non-destructive examination results, remaining strength calculation, repair method and closeout, with the response clock visible.
• Tool performance tracking per vendor per run, built from field verification against calls.
• Reassessment interval planning driven by growth rates and the applicable regulatory basis, with the supporting analysis retained.

What it costs and how long it takes

From the pipeline and infrastructure work Digital Heroes has delivered, this is the shape. A first release covering alignment, cross-vintage anomaly matching, dig prioritisation and closeout evidence runs $100,000 to $200,000 and ships in 14 to 20 weeks. A full platform adding attribute confidence modelling, in-house risk algorithm execution, reassessment planning and integration with GIS and work management runs $300,000 to $700,000 phased over 9 to 18 months.

Pipeline specific cost drivers: the number of distinct inline inspection vendors and report formats in your history, because each vendor's deliverable structure is its own ingestion problem and older runs arrive in formats nobody supports any more. Centreline quality, since an operator whose spatial data carries unreconciled station equations and acquisition-era re-routes needs remediation before alignment can work at all. Both gas and liquid assets under different regulatory subparts, which means two rule models. And risk algorithm complexity, because moving a consultant's model in-house is a specification exercise before it is a coding exercise, and the specification is the slow part.

What holds cost down: starting with the lines that have three or more runs, since those are where growth analysis pays, and leaving the risk algorithm to phase two until alignment and attribute confidence are trusted, because a risk model built on distrusted inputs will not be used.

Build versus buy, and when buying is right

Buy, or stay with the vendor platform and a consultant, if you operate a few hundred miles with a single inspection vendor and one or two prior runs. Alignment across vintages is not yet your problem, and the money is better spent on records validation that will pay off whenever you do build.

Build when two or more of these are true. You have used more than two inline inspection vendors and alignment is done in spreadsheets. You operate several thousand miles, particularly if assembled through acquisition, so centreline and attribute quality vary by legacy system. You cannot re-run your own risk algorithm without a consulting engagement. Your dig closeout evidence is assembled after the fact from work orders and PDFs when an auditor asks. Or you cannot say, per vendor per run, how the calls compared against what the excavations actually found.

The threshold is analytical independence. A program where every important question requires a vendor or a consultant to answer is a program that cannot respond quickly when a run comes back with something unexpected, and speed of response is what the regulation is fundamentally about.

How to choose a developer for pipeline integrity software

Ask them how they would align two runs where one tool missed roughly one girth weld in forty. A developer who has done this will describe sequence matching with tolerance for omissions and a confidence score. A developer who describes matching on distance alone has not seen a real inline inspection deliverable and will produce a crosswalk your engineers reject.

Ask what they would do with a segment whose seam type is unknown. The right answer treats it as uncertainty carried into the risk output, not as a default value. Silent defaults are how integrity software loses the confidence of the engineers who have to sign the decisions.

Ask which inspection vendor report formats they have ingested, by name, and whether they have handled runs older than a decade. Format archaeology is a genuine part of this work and experience is visible immediately in the answer.

Ask how the regulatory response clock will be computed and evidenced, and who signs off that the calculation matches your procedures. Then settle code and infrastructure ownership in writing before kickoff, which at Digital Heroes means the client owns the repository from the first commit. A practical starting point: take your two most recent runs on one line and ask how long the alignment took and what confidence anyone would put on it. That answer scopes the first release.