Designing a field command layer that assists and never authorises

Context

An upstream oil and gas producer develops its acreage the way a factory runs a line. Pads are prepared, wells are drilled, completed and brought on stream in sequence, and the product moves through gathering, treatment, storage and dispatch. Each stage has its own systems, contractors and reporting rhythm. A slip in one, such as sand, water or diesel reaching a completion crew late, surfaces later as cost in another.

This case describes solution design prepared for a proposal. There was no contract, no access to the operator's systems or data, and no structured discovery. The design drew on how operations of this kind are known to run and on limited informal input, none of it validated with the operator's teams. We publish it because the design reasoning, above all the safety rules, can be assessed by a peer on its merits.

The challenge

Without discovery, what follows is a set of working hypotheses about operations of this kind, not findings from the operator. Decisions lag the field. Drilling telemetry, SCADA, production systems, work orders and logistics each live on their own screen, so nobody sees plan against reality along the whole chain. When a crew is unsure how much weight is reaching the bit, it slows rotation to stay safe, and that caution becomes a cost nobody adds up.

Procedures are hard to reach at the point of work. Operators search folders, PDFs and radio channels for the current version of an isolation or start-up procedure. Operational memory sits in free text: years of daily drilling reports and shift logs that cannot be queried, while each new report is rebuilt by hand from data that already exists.

One subtler problem: documentary delays, such as custody-transfer paperwork arriving late, can be read as physical losses. A command view has to tell the two apart, or it sends people to look for barrels that were never missing.

Our approach

We worked from one axiom: nothing can be optimised until reality is captured. The design moves in five steps (measure, register, analyse, turn into intelligence, optimise) and does not skip ahead. We built it as a working browser prototype, not a slide deck, so that it can be interrogated and not only watched.

1. 1Map the chain, not the departmentSeven stages from pad readiness to storage and dispatch, with logistics and inventory cutting across them. Each view sets plan against actual, so a late convoy reads as margin, not minutes.
2. 2Choose narrow, assistive AI casesThree bounded use cases, chosen where records usually exist digitally already. In each, a person validates the output and takes the decision.
3. 3Write the safety rules into the specificationTrust principles, gates and refusal conditions sit in the specification the assistant's screens were built from. The interface follows the rules, not the reverse.
4. 4Propose discovery before buildThe proposal puts a three-week discovery (interviews, friction map, use-case matrix, tailored playbook) ahead of any construction budget.

What was designed

The command layer

The prototype has two levels. A control room follows the hydrocarbon from drilling to dispatch through eight views, among them geosteering, drillstring economics, well production control and critical alerts. Its recommendation panel is designed to reason only over signals an operator of this kind already collects; in the prototype those signals are simulated. Four scenario modes show the same field under different conditions, from baseline to optimisation applied.

Above it sits a chain-level command view: the seven connected stages, a logistics layer for sand, water, diesel, chemicals and spares, an inventory cockpit and an event stream. In a what-if console a planner moves one variable and watches logistics, inventory, forecast, cost and stage risk recalculate together.

The field-procedure assistant

As designed, an operator identifies the asset, for instance by scanning its tag, and asks a question. The assistant answers only from controlled documents for that asset and cites the source for every instruction. The prototype shows this on mock documents, not the operator's procedures. Each answer passes seven gates, from asset context and version control to human validation and traceability. Four situations are designed as refusals or escalations:

• Missing context. No asset, no answer. Generic isolation guidance is treated as unsafe for field execution.
• Obsolete document. Shown as obsolete and never used as the basis of an answer.
• Conflicting current documents. The assistant gives no sequence and escalates before any field guidance.
• Emergency. Normal procedural guidance is suppressed.

Two companion use cases

Operational memory is designed to turn past reports into structured events. Each event stays anchored to its source passage, carries field-level confidence, and has its cause tagged as reported fact, hypothesis, unknown or conflicting. A person validates extractions before they count as trusted data. Structured memory supports engineering judgement and does not replace it.

Daily report drafting aligns rig activity, comments, alerts and service inputs into a draft daily drilling report, which stays a draft until a person approves it. Uncertain causes and missing comments are flagged, not filled in. Possible non-productive time waits for official classification, and corrections are stored with the approved version.

Results

There are no outcome figures in this case, and that is deliberate. The prototype's screens show values for procedure search time, report compilation time and decision latency, but they are simulated placeholders, not projections from a baseline. We publish none of them and offer no hours, return or headcount estimate.

What the work produced is a design that an operations leader, a safety manager and an IT architect can each challenge from their own side. Were it to proceed, a pilot would first take a baseline for the same indicators: time to find the current procedure, supervisor calls on low-risk queries, hours spent compiling the daily report, and the lag between a field event and a decision. No contracted engagement is claimed.

Governance and risk

Assist, do not authorise. The assistant explains, cites and escalates. It does not replace supervisor approval, permits, lockout and tagout, control-room coordination or formal operating authority. Asked to go further, its designed reply is that it can summarise the approved sequence and show the source, but cannot authorise execution. By design, relevant consultations are logged.

Deployment follows criticality. The design allows on-premise, private-cloud or hybrid deployment depending on how close a component sits to operational technology, and holds that field and production data is never used to train public models. These are design positions; none has been through an operator's security review, which is where a real engagement would begin.

What we learned

• Write the refusal conditions before the interface. What a field assistant will not answer defines its safety more than what it will.
• Show plan against reality along the whole chain. A delay's cost often lands in a later stage, where a single-stage dashboard cannot see it.
• Label simulated figures as simulated on every screen, and publish no impact number until a baseline has been measured in the field.

Client identity, locations and identifying details are withheld under confidentiality. Figures are rounded. Measured figures come from engagement records; client-reported figures are attributed, not audited; modelled figures are projections from the engagement's business case and are labelled as such.