Count the tags on one pressure transmitter. Not the measurements it takes, the tags it puts on the wire.
There is the reading. Then the high alarm limit, the low, usually a high-high and a low-low, sometimes a deadband or a delay timer. Then a boolean for each of those limits being violated right now, and often an acknowledged flag alongside. One instrument, eight tags before you have counted anything unusual.
Nobody in a scoping meeting knows this, which is why tag counts get quoted as though they were instrument counts. They are not close.
Why one instrument becomes eight tags
Add a calculated tag, a rolling average or a rate of change computed in the PLC, and the same transmitter is at nine or ten.
None of this is a defect. It is how control systems are built. Every one of those tags exists because some piece of control logic or some operator screen needs it, and the engineer who configured them was not thinking about your warehouse.
The trouble starts when a pipeline treats all eight the same way. Seven of them are not measurements, and only one of them behaves like a time series.
What five thousand tags turned out to be
We pulled and classified every tag one SCADA platform would show us. Roughly five thousand of them, on one platform in one estate, so read the proportions rather than the digits.
| Tier | Share | What it is |
|---|---|---|
| Measured | ~69% | Live process values. Pressures, temperatures, levels, rates, runtimes, positions |
| Configuration | ~19% | Alarm limits, deadbands, timers, scaling factors, control parameters |
| Alarm bits | ~6% | Boolean state, one per limit |
| Calculated | ~3% | Derived in the PLC or SCADA layer, not read from an instrument |
| Silent | ~2% | Recorded range never left zero across the tag’s whole lifetime |
| Faulted | ~1% | Reporting bad quality or a device fault at capture |
Two caveats before anyone quotes that table. The alarm-bit count is a floor: we could only match a bit to its parent analog where the two shared a naming convention inside the same facility, so wherever naming diverges the bits are still sitting in the measured row, inflating it. And the whole thing is one platform, one estate, at one moment.
The line that should stop you is the second one. Nearly a fifth of what this platform calls a tag is configuration.
Setpoints are not time series
A setpoint that changes twice a year does not belong in a table partitioned by minute.
Land it that way and you get a row per scan per setpoint, forever, where every row is identical to the one before it. On a five-thousand-tag platform at one-minute resolution, the configuration tier alone generates on the order of half a billion rows a year, carrying almost no information. You pay to store it, you pay to scan past it, and every query against the measured tags has to filter it out.
The right shape is a type-2 slowly-changing dimension. Current value, effective-from, effective-to, changed-by if the system exposes it. dbt snapshots do this natively and it is roughly fifteen lines of configuration per source. You keep the full history of what the limit was on any given date, which is exactly the question people actually ask, and you keep it in a few thousand rows instead of a few hundred million.
This matters more than it sounds, because the question does get asked. When a well is being investigated after a workover, somebody wants to know what the high-pressure trip was set to in March. A slowly-changing dimension answers that in one query. A time-series table answers it too, eventually, after someone writes a window function over half a billion identical rows.
The classification has to happen before ingestion, though. Once everything has landed in the same table you have lost the distinction, and recovering it means inferring intent from change frequency, which is exactly as unreliable as it sounds.
Where this lands in the medallion
The tier is a property of the tag, not of the reading, so it belongs in the tag dictionary that the silver layer already maintains. If you are running medallion architecture on operational data, the classification sits alongside the tag-to-well mapping and the unit normalization, and it is versioned the same way.
Bronze still takes everything. That does not change. Bronze is the replay layer and it should be indiscriminate.
Silver is where the tiers diverge. Measured tags flow into the normalized time-series model. Configuration tags flow into the slowly-changing dimension. Alarm bits flow into an event model. Calculated tags get a provenance flag, because a totalizer computed in the PLC and a totalizer computed in dbt are different things and someone will eventually compare them and find they disagree.
Calculated tags are the ones to watch. A calculated tag is somebody else’s transformation, run somewhere you cannot see, on a version you cannot pin. Treat it as a raw measurement and you have silently inherited logic nobody on your side has reviewed. Flag it at ingest, and when the two totalizers disagree you will know which one to check first. Cheap to encode as a dbt test, expensive to discover during close.
Silent and faulted tags earn their keep
Three percent of the census was silent or faulted. It is the smallest slice and the most immediately useful.
A silent tag is a question, and importantly it is not automatically a defect. A large share of ours were safety detectors: H2S and LEL heads that have correctly never alarmed. A gas detector reading zero for two years is working. Others were unwired I/O on a skid that was never fully commissioned.
The distinction needs a human, per tag, and that is the actual finding. You cannot infer from the data alone whether a silent tag is a healthy detector or a dead one, which means any plan to prune silent tags at a license renewal has to go through somebody who knows the equipment. Prune a never-alarmed gas detector and you have saved a license fee by removing a safety signal.
Faulted tags are more direct. They are the system telling you which instruments are unhealthy right now, in a list, without anyone having to open a screen.
Neither of these requires the pipeline to be finished. Both come out of the census itself, on day one, and both are things operations will act on immediately. If you need an early win to justify the rest of the program, this is usually it: a list of instruments that are configured and not working, which nobody had assembled before because no single screen shows it.
Classify first, then quote
The practical sequence is short.
Pull the full tag list with whatever metadata the platform exposes. Classify each tag into the six tiers, mostly by naming convention and data type, with a manual pass on whatever the pattern matching cannot place. Count each tier. Then decide what actually needs to land as time series.
On ours, configuration plus silent plus faulted came to a little over a fifth of the count, none of it needing to land as time series. Those tags are not unimportant. They belong in a different shape.
The number you quote, the storage you plan, and the model you design should all sit on the tier breakdown rather than the headline. As the first part of this series argued, that headline is already the wrong denominator once facility tags are accounted for. Break it down twice, by attribution and by tier, and the estimate starts describing the work.
One number we deliberately did not produce: how many physical instruments those tags represent. The eight-to-one ratio holds for a transmitter with a full alarm set and not for a runtime bit or a totalizer, so dividing the total by eight would have been a tidy figure with nothing behind it. If you want an instrument count, count instruments.
And treat every figure here as provisional, because raw tag counts are wrong in specific, repeatable ways. That is the next post in this series.