Match Your Surveillance Ambition to Your Edge
The analytics you can credibly run on an asset are bounded by what it measures. Buying above that line does not raise the ceiling.
By John Wassilak
The demo always runs on a well with a variable speed drive, downhole gauges, and a decent comms link. Real-time optimization, failure prediction, the whole thing. It is genuinely impressive and it is genuinely working.
Then you go look at the asset you were planning to deploy it on, and it has a runtime bit, a tank level, and a pumper who drives out twice a week.
The analytics you can credibly run on an asset are bounded by what that asset measures. Buying ambition above that line does not raise the ceiling. It just costs money.
Three tiers, and what each one actually requires
Sorting an estate into tiers of surveillance ambition is more useful than sorting it by production or by basin, because it tells you what to build.
| Tier | What the asset reports | What you can actually do |
|---|---|---|
| One: alarm and status | Runtime, fault bits, maybe a tank level and a daily total | Know when a well went down and for how long, rank assets by downtime, catch a failure the same day |
| Two: production surveillance | Tubing and casing pressure, line pressure, flow, temperatures, sub-hourly | Variance against expectation, deferral quantification, trend detection, the resolution-gap use cases |
| Three: optimization | Dense lift-specific telemetry: dynamometer cards on rod pump, drive feedback on ESP, injection response on gas lift | Setpoint recommendation, failure prediction with usable lead time, closed-loop control |
Tier one deserves more respect than it gets. For an asset currently checked by a pumper twice a week, same-day downtime notification is the single largest available improvement, and it needs no new instruments at all.
Tier two is where most of the value at most operators sits. Tier three is a small number of assets and a real capital conversation.
The tiers are cumulative, and the boundaries are set by measurement rather than by software. No platform moves an asset up a tier. Instruments do.
What buying above your tier looks like
The specific waste is easy to describe.
Take streaming infrastructure on a tier-one asset. You stand up sub-second ingestion, streaming compute and a real-time serving layer for an asset whose entire signal is a runtime bit and a daily total, which means paying continuous-processing costs to deliver a latency improvement nobody downstream can act on. The pumper drives out on the same schedule. The work order gets raised the same morning. You bought milliseconds into a loop measured in days.
Failure prediction on tier-two data is the expensive version, because it fails quietly. A model predicting rod pump failure needs the signal that precedes failure, and that signal lives in load and position data. Give it pressures and runtimes instead and it still trains. It still produces probabilities. It still backtests well, because there is enough correlation lying around to look predictive.
Then it goes to production and does nothing useful, and establishing that takes a couple of review cycles and most of the credibility the program had.
The shape is always the same. Analytics built above the instrumentation tier produce output that looks correct and cannot be acted on, which is worse than producing nothing at all.
Audit the edge before you scope the analytics
The useful exercise is per-asset and is short once you have a tag census.
For each asset, establish what is actually measured, at what frequency, and how reliably it arrives. Then place the asset in a tier. Then, separately, write down what instrumentation would move it up one tier and roughly what that costs.
That last column is the one that changes conversations. “This asset is tier one, and three pressure transmitters plus a comms upgrade would make it tier two” is a fundable proposal with a defined outcome. “We should do more with our data” is not.
It also surfaces the assets where the answer is no. An asset with a handful of low-rate wells, poor comms, and no near-term development is a tier-one asset and should stay one. Instrumenting it to tier two is a real capital decision with a real payback calculation, and frequently the calculation says do not. Writing that down is a result, not a failure, and it stops the asset appearing in every roadmap as perpetual future work.
This is the same discipline as sequencing an ingestion program. Prove the pattern where the conditions support it, expand on evidence, and be explicit about what is out of scope and why.
The one thing to do regardless of tier
There is a single technical decision that keeps the tiers from becoming permanent, and it is easy to get wrong early.
Do not pre-aggregate at ingest.
The temptation is understandable. A tier-one asset produces a runtime bit and a daily total, so why land raw scan data when the consumer only wants dailies? Aggregating at the edge or during ingestion reduces volume and simplifies the model.
It also destroys the option. When that asset gets instrumented, or when somebody wants to reconcile electronic tickets against telemetry, or when a dispute needs the sub-daily profile from eight months ago, the raw data has to exist. Aggregation is cheap to do later and impossible to undo.
Land raw in bronze, aggregate in the transformation layer, and let the medallion structure carry the summarization. The storage cost of raw scan data on a sparsely instrumented asset is trivial, precisely because the asset is sparsely instrumented. This is the cheapest optionality available anywhere in the stack.
Comms is the constraint people forget
Instrumentation gets the attention in these conversations. Communications quietly decides more of the outcome.
An asset can be well instrumented and still be tier one in practice, because the link back is a cellular modem on a marginal signal that manages a few polls an hour, or a radio network sized for a much smaller tag count years ago. The measurements exist at the device and arrive at the historian aggregated, delayed, or with gaps.
This produces a specific and confusing symptom: the tag list looks tier two, the data does not behave tier two, and nobody can explain why the trends look coarse. The answer is usually bandwidth, and it is discoverable by comparing device scan rate against what actually lands.
Check it as part of the same audit. For each asset, what is the link, what is its practical throughput, and what is the observed arrival rate against the configured scan rate. An asset where those two diverge has a comms project ahead of it, not an analytics project, and the comms upgrade is frequently cheaper than the instruments.
What tiering changes about the roadmap
Once assets are tiered, the program stops being one initiative and becomes three, with different economics.
The tier-one work is broad and shallow: get every asset reporting downtime reliably, into one place, with alerting. It touches the most assets, costs the least per asset, and produces the most immediately visible operational change.
The tier-two work is where the analytical value concentrates and where the digital twin conversation actually starts to mean something. It should follow tier one rather than run alongside it, because it depends on the same identity and time-alignment work.
The tier-three work is a small number of assets, a real capital conversation, and a genuine pilot. Treat it as an experiment with a hypothesis, not as a rollout.
Trying to run all three at once across a mixed estate is how these programs stall. Every asset gets a little attention, no tier gets finished, and the demo that impressed everyone remains a demo.
The uncomfortable version of this is that some assets should stay at tier one permanently, and saying so out loud is a service to everyone. An asset that appears in every roadmap as future work, year after year, is consuming planning attention it will never repay.
Write down which ones those are. Then stop putting them in the roadmap.