Somebody hands you a tag count. Before you quote against it, assume it is wrong, because we reconciled one against the facilities and wells it claimed to describe and found eight separate ways it lied.
Not eight categories of possible error. Eight actual ones, on one platform, in one estate, in a single pass. All of them cheap to check.
Here they are, roughly in order of how badly each one will hurt you.
1. The same well, counted at two levels
A well appears as a node in the site hierarchy and again as a well under a pad, with tags under each. Sometimes those are genuinely different measurements, facility-side and wellhead. Sometimes it is one instrument published twice.
Group on the device identifier rather than the tree position. Two nodes resolving to one device is one well.
2. One instrument, two site names, identical readings
We found a disposal instrument publishing under two different site names, reading exactly 111,690,848 on both at the moment we captured it.
An eight-figure non-round number matching to the digit across two names is not coincidence. It is strong evidence of one skid published twice.
It is not proof, and the honest version of this finding says so. Our capture was a single instant, not a history, and the one historical dimension we did have disagreed: the two tags record different lifetime minimums, which is exactly the sort of thing that happens when one node is created later than the other. Duplicate, near-certainly. Confirmed, only by someone checking the field.
Run the totalizer comparison across your candidate duplicates before assuming you have two assets. Then go confirm.
3. Two naming conventions for the same well, inside one facility
This is the one that cost us the most time and produced the largest error.
Within a single facility, telemetry tags used a zero-padded well prefix while setpoint tags used an unpadded one. Well01_ for the live values, Well1_ for the configuration, same physical well.
Any prefix-based grouping treats those as two wells. On the facility where we found it, that single inconsistency overstated the well count by 100 percent. Not 10 percent. Double.
The failure mode is worse than the number, because prefix matching is exactly how most first-pass inventory scripts work. It is fast, it is obvious, and it is wrong in a way that looks entirely plausible in a spreadsheet.
Normalize the identifier before grouping. Strip padding, case, and separators, then group. Then look at what collapsed and confirm it should have.
4. Wells named Well1, Well2, Well3, and nothing else
A large number of wells in the tag database carry no identifier that ties to anything outside the SCADA system. No API number, no lease name, no cross-reference of any kind. Just an ordinal position inside a facility.
The tags are real and the measurements are real. The well is unidentifiable without somebody who knows the site walking you through it, pointing at equipment.
This is the finding with the longest tail, because it silently invalidates a plan rather than a number. Every SCADA integration proposal contains a line about mapping SCADA wells to the production system, and everyone reads that line as a transformation problem. Where the SCADA side has no key at all, it is not a transformation problem. It is fieldwork, scheduled with somebody who has other things to do, and it does not compress.
So the number to establish early is not whether this occurs but what fraction of wells it covers. Ten percent is an afternoon of phone calls. Half the estate is a work stream, and it belongs in the plan as one before anybody commits to a date.
It is the same identity problem we wrote about in building a single master well table without an MDM platform, with the difficulty that there is nothing on the SCADA side to join on. An MDM exercise reconciles two imperfect keys. This reconciles one key against a person’s memory.
5. Well-group assignments that are inverted
At one pad, every tag named for one well sat in the group named for the other, and vice versa. Ten tags, tank levels and volumes and a treater pressure, in a pattern consistent with two groups having been swapped at configuration time.
Nothing errors. The tags report, the screens work, and the operators know which well is which because they know the site.
Detecting it needs nothing external, which is the useful part: the tag names and the group names disagree with each other, and that comparison runs entirely inside the export. What you cannot do from inside is say which side is right. The tag could be misnamed or the group could be misassigned, and only somebody at the site can settle it. Detect internally, resolve externally, and present it as an open question rather than a correction.
6. Injection wells with no well attribution at all
Injection and disposal tags frequently sit at the facility level with no well association, even where the injection well is a real, permitted, individually metered well.
The instrumentation follows the skid, not the wellbore. From the SCADA system’s point of view there is a pump, a pressure, and a rate. The fact that the fluid ends up in a specific well is knowledge that lives in the permit, not the tag database.
If your model requires every measurement to hang off a well, injection is where it breaks first. This is another argument for the facility being a first-class entity, which the first post in this series makes at length.
7. Tag names collide inside a single facility
We counted 19 tag-name collisions across seven facilities, with eight of them concentrated in a single pad. Same name, different device, different meaning. Several of the colliding names occur three times, so more than 19 tags are involved.
This is the one that corrupts a pipeline silently. Two tags called the same thing, joined on name, produce a merged series interleaving readings from two instruments. It plots cleanly, it has no gaps, and it is nonsense.
The rule that falls out of this is short and worth taking literally. Key on the tag id, never on the tag name. Names are for humans and for screens. They are not unique, they are not stable across renames, and they are not a join key. The platform we inventoried exposes a stable internal identifier and our collector deduplicated on it, which is the only reason the collisions were countable at all; OPC UA node ids and historian point ids play the same role elsewhere. Find the equivalent on your platform, carry it through bronze and silver, and treat the display name as an attribute rather than a key.
If your ingestion already joins on name, this is worth checking today rather than at the next design review. It is a data quality gate that costs one unique test on the tag key in a dbt schema file, and it fails loudly the first time it runs against a facility like the one above.
8. The count itself is a floor
The last one is a property of the exercise rather than a defect in the data.
A tag census tells you what the platform exposed to the interface you queried, during the window you observed. It does not tell you about tags on devices that were offline, tags below the level the interface exposes, tags on equipment that is installed but not yet integrated, or tags on the platforms you have not censused yet.
Every number in this series is a floor. The right way to present a census is with that stated on the same page as the number, because the number will get quoted, and it will get quoted without the caveat unless the caveat is attached to it.
What to do with the list
Run all eight as checks before the count leaves your desk. Most of them are queries against the tag pull itself: group on device id, compare normalized identifiers, look for repeated names, compare tag names against group names. The unidentifiable wells are the one case needing an outside reference to resolve, and the duplicates and inversions need field confirmation before you act on them even though you can detect them from the export.
The failure that connects all of them is treating the SCADA system as an inventory. It is a control system that happens to contain an inventory-shaped thing, maintained by people whose actual job was keeping the plant running. The naming inconsistencies and the stale nodes are the residue of years of operational reality and more than one change of owner.
That is also why this reconciliation is not a one-time task. New wells come online, sites get renamed, equipment gets decommissioned. The checks belong in the pipeline as tests, not in a spreadsheet as a milestone.
“How many wells do we have” has several defensible answers depending on which system you ask, which is the same reason well data is not a data product until somebody owns the definition. Any interface that answers the question confidently before that work is finished is doing damage rather than saving time.
A tag count is that problem in miniature, and it is the version you can fix this month.
None of the eight above required special tooling. They came out of a spreadsheet, a few hours, and a willingness to disbelieve the first number. The count is easy. The count being true is the job.