Applying to field data the rigor of an accounting ledger does not protect it: it chokes it.
This note is part of the series Two strategies over the same estate. On top of the tension between the two strategies, a third force tends to come down, presented as the sensible solution: data governance. The intention is good and the need is real. The problem is how it usually comes designed.
Almost always it comes modeled like an accounting ledger. Maximum rigor, immutability, approvals, every piece of data validated and signed before it exists, a single official path for every number. That logic is exactly the right one for a system of record: accounting, assets, contracts, everything that has to be auditable and cannot change without leaving a trace. There, rigor does not get in the way, it protects.
But that same logic, applied to the operational data stream, suffocates it. Field data is not born perfect and cannot wait to be. A drilling report, a sensor reading, a completions progress update, a crew event: that has to flow in minutes, not in approvals. It is useful even when incomplete, and it gets corrected downstream.
If you demand of operational data the same rigor you demand of an accounting entry, one of two things happens. Either the operation stops to wait for the validation. Or people build a parallel path outside governance so they can work, and you are back to the spreadsheets in the shadows you wanted to eliminate, now with the blessing of having "implemented governance".
That is the central mistake. It is not that the rigor is wrong. It is that the rigor of one thing is applied to the nature of another. An accounting ledger and a flow meter measure different realities. No one would want the flow meter to stop at each reading to ask for three signatures. Data governance that does not distinguish between the record and the stream ends up imposing on the flow the cadence of the ledger, and chokes the operation in the name of protecting it.
The way out is not to have less governance. It is to have the right governance for each type of data: rigor where the consequence calls for it, speed where the operation demands it. With the trap in view, the middle path begins, and it begins with the most down-to-earth thing: how to deliver visible value soon and how to map honestly what there is. It continues in the next note.
Glossary
- System of record
- The official, auditable source of a piece of data: accounting, assets, contracts. It needs rigor, immutability and traceability, and can afford to be slower because its value is that no one can dispute it afterward.
- Operational data stream
- The data flow that is born in the field and has to move at the speed of the operation: reports, sensor readings, progress, crew events. It is useful even when incomplete and is corrected downstream; demanding record-level rigor of it suffocates it.
- Data contract
- Explicit agreement at the interface between two systems on the data schema, the meaning of each field, and the quality and frequency guarantees. It decouples producer from consumer, so each can evolve internally without breaking the other.
- Fit-for-purpose governance (by consequence)
- A governance model that classifies data by how it is used and by the consequence of it being wrong, and applies rigor in proportion to that consequence. It avoids both the lack of control where the decision is grave and the pointless ritual where it is not.
- Quality at the source
- Validating the data where it is born, with simple rules and immediate feedback to whoever enters it. It costs far less than rebuilding quality downstream and is the cheapest way to keep an error from propagating.
- Progressive rigor
- A governance strategy that starts light, with visibility and contracts over the few highest-consequence flows, and adds control where the consequence justifies it. It is the opposite of a total program that tries to govern everything at once and never finishes.
- Vendor lock-in
- A situation in which the operation ends up tied to the roadmap, prices and timelines of a single vendor or platform, because it bet everything on it. Standardizing the connective tissue instead of the application is what preserves optionality and avoids being held hostage.
- Connective tissue
- The set of connections through which the pieces of the ecosystem talk to each other: interfaces, identity, data contracts, observability. Standardizing the connective tissue, and not the application, is what lets you change any piece without redoing the whole.
- AS-IS (current state)
- The honest map of how the application estate stands today: what exists, what is obsolete, what depends on what. The real starting point, unretouched.
- TO-BE (target state)
- The direction the ecosystem is meant to be taken in, drawable and debatable, corrected as you go. Not a fixed snapshot, but a firm heading.
