One of my favorite keynotes at PRCI wasn’t about pipelines at all. It was about airplanes.
The speaker was from the Federal Aviation Administration, and he was describing one of the biggest challenges his industry had faced. You’d assume he meant a crash, or some regulatory crisis that followed one. What he actually meant was that commercial aviation had become too safe. Catastrophic failures had gotten rare enough that the industry was running out of failures to learn from, which is a real problem when your entire safety culture is built around dissecting and learning from accidents, i.e., the black box, the NTSB report, the airworthiness directive that follows.
So aviation went looking for a different kind of data, and the catalyst was one specific accident. On December 1, 1974, TWA Flight 514 flew into a mountainside near Berryville, Virginia, killing all 92 people on board. The investigation found the flight crew had misunderstood an air traffic control clearance. Six weeks earlier, a United Airlines crew had misunderstood the same clearance and nearly hit the same mountain. They caught it, they reported it, and their airline knew about it. There was simply no mechanism to get that information to TWA, or to anyone else. One operator had the lesson, and it stayed inside that operator. A process for shared learning could have prevented this incident.
Out of that came the Aviation Safety Reporting System in 1976, administered by NASA rather than the FAA specifically so it could be voluntary, confidential, and non-punitive. Report your near miss, and you aren’t handing a regulator a case against yourself; you’re handing the industry a lesson. ASRS has since collected more than two million reports. Aviation later extended the same logic to operational data with ASIAS, where dozens of carriers pool de-identified flight data to hunt for the precursors to accidents rather than waiting on the accidents themselves.
Two things had to happen for any of that to work. Operators had to share what they learned, and they had to share the underlying data. That’s the whole model, and I’d argue it’s the model for where pipeline integrity is headed too. This post is about the first half. The second half, shared data, is its own post. Back in January, I made the case that pipeline integrity runs on unified data, i.e., getting your own inspection, pipe, repair, and assessment data validated and aligned enough to trust. That's the foundation. This post is about what you build on top of it once the unified data is there.
Significant pipeline incidents are rare relative to the miles we operate, which is the entire point of an integrity management program and a genuine achievement. But rarity creates a blind spot. Any single operator, over any reasonable time horizon, sees a very small sample of the things that can go wrong: your corrosion growth data, your dents, your one crack colony that didn’t behave the way the model said it would.
Meanwhile, the precursors are everywhere. A misclassified anomaly. A vendor call that didn’t hold up in the ditch. A CIS survey interpreted three different ways by three different technicians. A dent that got deprioritized and shouldn’t have. None of those are incidents. All of them are lessons, and almost all of them stay inside the company that learned them.
What if the industry treated its precursors the way aviation treats a near miss?
I’ll say the quiet part out loud. We take good ideas from everywhere we can find them, and then we build them into the platform so every operator on it gets the benefit.
C-FER has the best risk models? We’ve built them in. One of our operators runs advanced analysis on their external corrosion survey data? We built conditions off that methodology and baked it into the external corrosion platform. Ted Anderson has a spreadsheet that calculates pressure cycling fatigue? That’s now in our advanced crack module. European operators analyze pipelines according to DNV RP-F101? We’re building that in so our integrity partner across the pond, Jee, can use it. PRCI publishes a spreadsheet for API 1163 ILI performance validation? That’s in the platform too, so unity plots and tool performance evaluations run against your aligned inspection history automatically instead of getting rebuilt by hand every time.
It’s the recognition that the best methodology in the industry is sometimes sitting in one company’s spreadsheet or one consultant’s report, doing a fraction of the good it could do.
The API 1163 example is exactly why we became PRCI members. Industry research, i.e., real, peer-reviewed, collectively funded work, only changes practice when it makes it into the tool people use every day. Research that sits in a PDF changes nothing.
This belief drives a choice that looks strange from the outside. We deliberately don't fork the platform into custom builds for individual clients. An operator's environment can look and feel like its own version, i.e., their tool selection, their thresholds, their reporting layout, but underneath it's the same codebase every operator runs, just configured to reflect how their program works. What we won't do is fork the platform itself, because the moment that happens, the learning stops moving. A methodology developed by one operator becomes a feature only that operator ever benefits from.
The shared condition library works the same way. Conditions are how integrity knowledge is encoded and how it can scale, and how knowledge can transfer. When an operator builds a condition that catches something the rest of us were missing, that logic shouldn’t stay in one tenant. The shared library of engineering calculations and attributes does the same for analysis: the process by which an engineer analyzes inline inspections and prioritizes anomalies for repair is often the most transferable thing they produce, and also the thing most likely to stay buried in a company's SharePoint.
And we conduct voice of customer interviews across multiple clients rather than designing a roadmap around a single loud voice, because the pattern that shows up in ten programs is worth considerably more than the request that shows up in one.
The User Summit builds on this very principle. Every year we get our clients in a room together, and the most valuable sessions are consistently the ones where operators talk to each other rather than to us.
So, an ask.
You think you have the best corrosion growth model in the business? Bring it to Irth. You’ve built a susceptibility model that outperforms what’s out there? Bring it. You’ve figured out how to reduce interpretation variability across your CIS vendors? We want it, and we want to get it to the operators who haven’t solved it yet.
I understand the instinct to hold it close, since integrity expertise feels like a competitive asset. But it’s worth asking honestly: What’s the point of building something that will only make your company safer?
We all know how this works in practice. One pipeline failure, in any operator’s system, lands on all of us. It shows up as a headline that names the industry rather than the operator, and then it shows up in the next rulemaking, the next permit hearing, and the next conversation with a landowner who’d rather your line not cross their property.
Rising tides lift all ships.
Sharing what we've learned costs nothing but willingness, and it's the easier half. Methodology only gets you so far without data to build on, which is the harder, more valuable half. That's part two.
If shared learnings are where we start, shared data is where we're headed, and it's further along than you might think.
Want to talk about contributing a methodology, or about what the shared learning via AIP can do for your program? Reach out, or come to our User Summit.