Oil and gas

inTheEU Assist  ·  Case study  ·  August 2026

Refineries, processing facilities, pipelines, and offshore platforms generate constant operational and inspection data that maintenance and reliability teams need interpreted quickly, without that interpretation ever gaining authority over process control. This page sets out how such a workflow would be planned and run on inTheEU Assist, not a record of a completed deployment.

Anomaly review, oil and gas workflow

How the workflow would be structured

Process and inspection data, compressor telemetry, pipeline monitoring, maintenance records, would be ingested and indexed on premises, feeding a knowledge pack scoped to the operator's own tenant. An agent configured for the workflow would compare current readings against approved operating history and propose candidate anomalies, each one tied to a specific asset and entered with a status of proposed. A recommendation to escalate, such as a targeted inspection or a maintenance work order, would follow the same proposed-to-approved path.

Existing operational technology, process control, safety instrumented systems, emergency shutdown logic, would remain entirely outside this workflow. The platform would never hold, request, or execute authority over those systems.

Where human approval sits

Every anomaly flag or escalation recommendation would require explicit approval from a named engineer before it is treated as established or acted on. This is not a policy layered on top of the workflow. It is the mechanism by which the workflow proceeds at all: an unapproved stage simply does not execute the next step.

What this draws on today, and what it does not

The anomaly-flagging workflow, the proposed-to-approved review lifecycle, and the signed audit chain behind every action are working parts of the platform. What is not yet part of this: a facility-specific model trained on a given operator's own process data, which is exactly what an initial pilot would build. Existing safety instrumented systems and process control remain outside the platform's scope entirely, by design. The domain judgement in an oil and gas deployment would remain with the operator's own engineers throughout, and any asset-specific analysis skill would be developed alongside them, not supplied as an off-the-shelf model.

Some of the architecture underlying this capability set is documented in filings still in progress. This page describes what the platform is designed to do, at a level appropriate for planning a pilot, not an implementation specification.

Platform features and interface are subject to continuous improvement. Descriptions in this guide may not reflect the exact layout or wording of the latest released version.