Selected work/Operations console
A field data model and browser console joining well status, rates, routing, flowline integrity, service tests, water systems and project delivery, with history kept on every refresh.
Outcome
Objective met4 of 4 success criteria. Read the conclusionWell status came from one export, allocated rates from another, routing from a planning list and flowline condition from a fourth system, each with its own date. The newest file won every argument, so a well could be shown flowing at a facility it had left. Engineers rebuilt the same picture by hand each week and management briefs disagreed with each other.
We designed the data model around canonical entities: well with aliases, facility, train, manifold, flowline, replacement project, work order and source. Precedence was set field by field. The latest flowing wells export governed status and receiving facility. The latest allocation export governed oil, water and gas and was never replaced by a test value without a flag. The master well list governed home facility. The signed test record governed service test position. The integrity export governed risk. Each stored value kept its raw and accepted form, source date, load time, authority rule, confidence and conflict flag.
Five layers were built: current, context, history, changes and sources. A well profile read in four views: now, context, history and changes, with routing shown as home facility against actual receiving facility. Most domains refreshed at the weekend, well status more often, with the data-as-of date shown for each. Facility flow diagrams and P&IDs were stitched into a process graph with designed, as-built, temporary, planned, isolated and flowing connections kept distinct. The build was SQLite and JSON behind a browser view, with a Power BI model from the same tables.
A query for any well returned a profile with every item sourced and dated and every open conflict shown. Facility summaries, deferral registers and forecast tables came from the same record and agreed with each other.
The objective was one record per well with every field sourced and dated, and management outputs that agree with each other. It was achieved. The console is in use across operations and engineering, substitutions and conflicts are flagged on each refresh, and facility summaries and deferral registers come from the same record.
| Success criterion | Met | How it was achieved |
|---|---|---|
| iA well profile answerable from one page, with the source and date of every field | Met | Console in use for well queries across the operations and engineering teams |
| iiNo silent substitution of a test rate for an allocated rate | Met | Substitutions flagged on the profile with the source and date of the value used |
| iiiUnresolved source conflicts visible, not averaged or hidden | Met | Conflicting values listed side by side on the data health report with both sources, nothing averaged; data-as-of date shown by domain on each weekly refresh |
| ivManagement outputs reconcile to the same record | Met | Facility summaries and deferral registers generated from the console rather than rebuilt by hand |
Deliverables
Evidence note
Work done for the operator of an onshore field in the Middle East. Architecture and rules as designed and built with the operator's exports. Operator not named.
Send us the version you are dealing with. We will tell you what we would do first.
hello@assostechltd.com · 5 South Charlotte Street, Edinburgh, EH2 4AN