Beyond the Historian

Digital Twins for Upstream Assets: What the Term Actually Means

A vendor will show you a rotating 3D model of a well pad, call it a digital twin, and quote you a number with a lot of zeros. Somebody on your team will ask what it does. The honest answer, most of the time, is “it displays the tags you already have, prettier.”

“Digital twin” is one of the least useful words in the upstream software market, because it covers everything from a well record in a spreadsheet to a coupled reservoir simulation that a PhD reservoir engineer babysits. Those are not the same product. They do not cost the same, they do not require the same data, and they do not solve the same problem. When a term spans four orders of magnitude of effort, it has stopped meaning anything, and it becomes a way to sell you the cheap version at the expensive version’s price.

This is the last post in the Beyond the Historian series, and it’s the one the earlier three were building toward. Convergence gave you a read-only path off the OT network. A namespace gave every asset and tag a stable address. Airflow moved the data on a schedule you can trust. A digital twin, at any level worth paying for, is what you build on top of all that. If the foundation isn’t there, the twin is a screensaver.

So here’s a spectrum you can actually use. Four levels. What each one is, what data engineering work it takes, and where a mid-size operator should stop.


Level 1: the well knows what it is

A Level 1 twin is a master record for the well with its current physical attributes. Wellbore geometry, completion design, the ESP or rod pump that’s in the hole right now, tubing and casing, the equipment on the pad. It is a description of the asset as it physically exists today. No live data. No prediction. Just an accurate, current, single-source-of-truth record.

Most operators believe they already have this. Most operators have a partial, contradictory version of it spread across four systems. WellView has the completion. The SCADA vendor’s portal has the current pump. A maintenance spreadsheet has last quarter’s workover. Accounting has a well number that doesn’t match any of them. The record exists. It just doesn’t agree with itself.

The data engineering work at Level 1 is entity resolution and a master well table. This is the least glamorous work in the entire spectrum and by far the highest return. You need one row per well, one durable surrogate key, and lineage back to every source system’s own identifier, because WellView’s idwell, the accounting well number, and the SCADA device ID are all different and none of them is clean enough to be the primary key. API number helps and is not sufficient; it changes on recompletion, it gets transposed, and it identifies a wellbore, not always the thing your business calls “the well.”

If you have adopted the PPDM model, Level 1 is a well-scoped subset of it: the well, wellbore, and equipment tables, populated and kept current. If you haven’t, it’s a conformed dimension. Either way, the deliverable is the same. One record per well that every downstream system can trust and point at.

A clean Level 1 foundation looks like this: an operator can ask “what pump is in well X and when was it installed” and get one answer, not four. That is the whole bar. Almost nobody clears it on the first try, and clearing it is worth more than any Level 3 pilot you could run on top of dirty identity.


Level 2: the twin reflects current state

A Level 2 twin is the Level 1 record wired to live SCADA. The static description of the well now carries its current operating state: tubing pressure, casing pressure, flow rate, pump status, whatever the historian is recording. The twin stops being a snapshot from the last workover and becomes a thing that tells you how the well is running right now.

This is where most operators actually want to be, and where most vendor “digital twin” products are actually pitched, whether or not they say so. The value is real and modest: a single pane where the asset’s identity and its live behavior sit together, so a surveillance engineer isn’t reconciling a pump spec from one screen against a pressure trend from another.

The data engineering work is the entire SCADA ingestion problem, which is why the earlier posts in this series exist. You need the tags flowing off the OT network on a read-only path, landed reliably, and, critically, mapped to the right well. The last part is where Level 2 quietly fails. A tag named PT_04471_TBG means nothing until it’s bound to a specific wellbore in your master table. If you have a unified namespace, that binding is already done, because the tag’s address encodes its asset. If you don’t, you’re maintaining a mapping table by hand, and it drifts every time a field tech renames a tag or a new pad comes online.

The ingestion itself should be orchestrated, not hand-rolled: batch pulls on a cadence that matches the use case, an overlap window for late-arriving points, reconciliation against the source. A clean Level 2 foundation is one where the tag-to-well binding is stable and audited, and where you can tell, on any given morning, whether the twin is showing you live data or stale data from a pipeline that quietly died at 2 a.m. A twin that confidently displays yesterday’s numbers as if they were current is worse than no twin, because someone will make a call on it.


Level 3: the twin predicts something

A Level 3 twin runs a model on the live data and forecasts something you can act on. Decline curve projections that update as production comes in. ESP failure probability from the current draw and temperature signature. Estimated runtime before the next intervention. This is the level where “digital twin” starts to earn the money the Level 1 version was charging.

It is also the level where the data foundation stops being a nice-to-have and becomes the entire game. A decline forecast is only as good as the allocated volumes feeding it, and allocation is one of the hardest reconciliation problems in upstream. A failure model trained on tag history is worthless if half the wells have clock drift, unit inconsistencies, or a six-month gap where the historian was down and nobody backfilled it. The model is not the hard part. The clean, gap-free, correctly-labeled training data is the hard part, and it’s the part the vendor demo skips.

The data engineering work at Level 3 is everything from Levels 1 and 2 plus a real analytical layer: historized, downsampled, quality-flagged time series, joined to a trustworthy well master, with enough labeled outcomes (this pump failed on this date) to train and validate anything. In practice this is a medallion-style build on PPDM, where the gold layer is the feature table a model actually consumes. Skip the silver layer and your model learns your data quality problems instead of your reservoir.

Here’s the opinion the vendors won’t lead with: a Level 3 twin built on a shaky Level 1 and Level 2 foundation will produce confident, specific, wrong predictions, and those are more dangerous than no prediction at all. A number with a decimal point on it gets trusted. If the well identity underneath it is wrong, you’ll pull the wrong ESP. The order of operations is not negotiable. Get identity right, get live state right, then predict. Anyone selling you Level 3 who hasn’t asked hard questions about your Level 1 is selling you a demo.


Level 4: the physics simulation

A Level 4 twin is a coupled physics model: reservoir simulation, nodal analysis, a full multiphase flow model that mirrors the physical system closely enough to run what-if scenarios. This is the thing most people picture when they hear “digital twin,” and for a mid-size upstream operator it is almost always the wrong thing to build.

Level 4 is real, and it lives mostly in reservoir engineering, run by people who do this for a living with tools like the major reservoir simulators. It is expensive to build, expensive to keep calibrated, and it answers questions (waterflood optimization, field development planning) that are genuinely worth simulating on a big asset with a lot of remaining value. It is not a data engineering deliverable. If you need one, you know you need one, and you have reservoir engineers who own it.

The honest position: most mid-size operators do not need a Level 4 twin and should not let a Level 4 vision drive a Level 1 budget. The place operators lose money is buying the ambition of Level 4, funding a project scoped like Level 4, and never finishing the Level 1 work that would have delivered value in the first quarter. Simulation is a specialty tool for a specific question, not a maturity target every operator should march toward.


A build sequence that finishes

If you’re starting from spreadsheets and a SCADA portal, the sequence is the same one that works for any upstream data foundation, and it maps cleanly onto the levels.

Build Level 1 first, completely, before anything else. One master well table, entity resolution done, every source system’s key reconciled to a surrogate. This is unglamorous and it is where the return is. Do not move on until an operator can get one answer to “what’s in this well.”

Then wire Level 2 on your cleanest asset only. Not the whole portfolio. One vendor platform, tags bound to wells, ingestion orchestrated and monitored, freshness you can see. Prove the pattern end to end on the asset with the best documentation and the most accessible API, exactly the crawl-walk-run logic the SCADA sequencing post lays out. Expand to the rest of the portfolio on the proven pattern.

Only then consider Level 3, and only for one concrete question with a clear payoff. ESP failure prediction on your highest-lift-cost wells. Decline forecasting on the assets where the forecast drives a real decision. Pick the use case where a working model pays for itself, build the gold feature table it needs, validate it against outcomes you can check, and resist the pull to “twin the whole field.”

Level 4 is a separate conversation, owned by reservoir engineering, justified per asset. It is not the finish line of this sequence.

The thing to take away is that a digital twin is not a product you buy. It’s a capability you build, level by level, on a data foundation that most of the term’s marketing quietly assumes you already have. The four levels are cumulative. You cannot skip to the interesting one. And the least interesting level, the master well record that agrees with itself, is the one that pays for all the others.

Next time a vendor says “digital twin,” ask which level, then ask what they assume about your well master. The answer to the second question tells you whether the first one is real.


Get in touch