How – Inside the AI OS: running governed agents on your own cluster, liveRegister →
Critical Infrastructure · Energy Networks

From documents to a connected procedure

A European gas transmission operator manages thousands of digital assets for every pipeline project — route plans in GIS, P&IDs and isometrics in an engineering vault, soil surveys, environmental permits, welding procedure specifications, hydrotest protocols, as-built dossiers. Every one of them is stored and findable, but nothing expresses how the pieces relate to each other or to the procedure actually being executed, so process compliance is reconstructed by hand at audit time.

The challenge

What stands in the way

A European gas transmission operator manages thousands of digital assets for every pipeline project — route plans in GIS, P&IDs and isometrics in an engineering vault, soil surveys, environmental permits, welding procedure specifications, hydrotest protocols, as-built dossiers. Every one of them is stored and findable, but nothing expresses how the pieces relate to each other or to the procedure actually being executed, so process compliance is reconstructed by hand at audit time.
The solution

How Scrydon solves it

An ontology models the domain in the operator's own terms — sections and segments, procedure steps, the standards, roles and documents each step requires, and what must complete before the next step starts — so procedure, evidence and status become one connected structure with gates the platform can check.
In practice

How this plays out

Everything a pipeline project produces is already stored and findable: route plans in GIS, P&IDs and isometrics in the engineering vault, soil surveys as PDFs, environmental permits, welding procedure specifications, hydrotest protocols, as-built dossiers. What no system holds is how those pieces relate to one another, or to the construction and operating procedure that is actually being executed — so process compliance gets reconstructed by hand, usually at audit time.

The answer is a model written in the operator's own terms rather than another document index. A pipeline section has segments, each with a design pressure, material spec and coating. A construction procedure is a flow of steps: route clearance, trenching, stringing, welding, NDT, coating, hydrotest, backfill, commissioning. Each step requires certain documents, is governed by certain standards such as NBN EN 1594 and ATEX zoning, is performed by certain roles, and must complete before the next step starts.

That last relation is what makes the process flow a first-class object with gates. NDT cannot begin until the welding procedure is qualified. The hydrotest cannot be scheduled while the permit is invalid for that date. Commissioning cannot be signed off until the as-built dossier is complete. Each gate is a rule on the graph, and each rule points at the documents that satisfy it.

Once the assets are mapped onto the model, "which documents must be approved before NDT starts on segment 14 of the coastal section, and are any out of date?" is a query rather than a search. Because the platform knows where each segment sits in the flow, it can flag today that a permit expires before the planned hydrotest, draft the step completion report from the underlying records, or show an auditor the evidence chain from the as-built weld map back to the design pressure.

The point is that procedures and documents stop being two things linked afterwards. The ontology models the process, its gates and its evidence as one structure, so compliance becomes something the platform checks continuously rather than something reconstructed at audit time.

Nothing about the model is specific to gas. Any linear asset built under a governed procedure — fibre and duct networks, rail, water mains — accumulates the same pile of documents against the same staged, gated process, and gains the same thing from connecting them.

Pipeline routing, pressure data, permit status and weld records are all critical-infrastructure information. The platform runs on the operator's own infrastructure, so none of it leaves their perimeter.

Explore Ontology Based Data Platform
A pipeline segment, its procedure gates and the documents each gate needsSegment 14 of a coastal pipeline section follows a construction procedure of four gated steps: welding, gated on an approved welding procedure specification; non-destructive testing, gated on the welds being complete; hydrotest, gated on a valid permit; and commissioning, gated on a complete as-built dossier. Each step points down to the document that satisfies its gate. The environmental permit required by the hydrotest is flagged by the platform because it expires before the planned test date.Pipeline sectionCoastal sectionSegment 14DN900, 80 barfollowsConstruction proceduregoverned by NBN EN 1594, ATEXWeldinggate: WPS approvedNDTgate: welds completeHydrotestgate: permit validCommissioninggate: dossier completerequiresrequiresrequiresrequiresWelding specv3, approvedNDT reportpendingEnv. permitexpires before test!As-built dossierin progress
  • Physical asset
  • Procedure step with gate
  • Required document
  • Flagged by the platform
Segment 14 of the coastal section: asset, procedure gates and required documents as one graph. The platform flags the environmental permit because it expires before the planned hydrotest.
The result
  • Process compliance is checked continuously against a live model instead of reconstructed by hand at audit time.

Or write to us

Tell us what you are working on and who should reply. A person reads it and replies within one business day.

We only use these details to reply to you. Privacy policy

Prefer to write? Email hello [at] scrydon.com and we will get back to you.