In the Australian pipeline industry, AS2885 is the standout standard for ensuring pipeline safety through its full lifecycle. Unfortunately (or fortunately), because it is such a solid Standard, it’s often treated as though it is a textbook and as if “it” designs/operates the pipeline.

It doesn’t.

Engineers do.

AS2885 provides the structured safety framework, covering threat identification and control, risk evaluation, design factors, and verification. But it deliberately avoids prescribing many detailed design and operational outcomes. That’s intentional. The standard assumes competent engineers will apply judgement to real-world conditions.

Problems arise when compliance replaces thinking.

Across projects and reviews, technical decisions are sometimes justified by citing clauses, rather than demonstrating engineering reasoning. Threat assessments become templated. MAOP becomes a spreadsheet output. Rupture mitigation becomes a checklist. Documentation exists, but the technical logic is thin.

Pipeline safety is not achieved through documentation (though that’s so very important); pipeline safety is achieved through knowledge and understanding.

Every pipeline has a unique combination of route, materials, operations, and protection systems. AS2885 expects engineers to interpret how these interact and to justify why the resulting design is safe.

A simple test of real competency is this:
Can the engineer explain why the design/operational condition is safe without immediately pointing to a clause?

Clause compliance should support engineering judgement, not replace it.

AS2885 defines the framework. Engineers deliver the safety outcome.

The difference is where professional competence lives.

(disclaimer: the above article is based on a bunch of dot points from me, but tbh, ChatGPT wrote it. And by admitting that here (I couldn’t publish without disclosing the AI input) … it’s probably the last time I’ll publish a ‘mostly AI’ article like this, because, I don’t like how it makes me feel. Interesting! …