This note is part of the series Two strategies over the same estate. We saw why the rigor of an accounting ledger chokes the operational stream. Here is the first half of a governance that can actually be put to run. The guiding idea: good governance is not the one that controls the most, it is the one that makes trustworthy data flow.
Separate the system of record from the operational stream. It is the distinction that orders everything else. The system of record needs rigor, immutability, auditability, and can be slower: it is the official truth that no one will be able to dispute afterward. The operational stream needs to flow at the speed of the field: timely, good enough, corrected downstream. Each has its regime. The sin is applying to the stream the rigor of the record, and the mirror sin is letting the fast stream pass itself off as an official record. You separate the two worlds, with a clear boundary of where and how an operational piece of data, once settled, is promoted to record.
Rigor by consequence. Not all data deserves the same control. A piece of data feeding a multimillion-dollar investment decision is not governed the same as one feeding an intraday tracking dashboard. The key is to classify data by how it is used and by the consequence of it being wrong, and apply rigor in proportion to that consequence. Treating everything with maximum rigor is not prudence, it is waste, and on top of that it trains people to dodge governance because they experience it as an indiscriminate obstacle. In a word, control is fit-for-purpose.
Governance that enables, and each domain owns its data. Governance's job is to make trustworthy data flow, not to stop the operation. That changes where responsibility lives. Ownership of the data has to sit in the domain that produces it, close to where the data is generated and where what it means is understood, not in a distant central committee that approves one ticket at a time. The central committee defines the rules of the game and measures them; the domain owner answers for its data. A centralized governance that becomes a bottleneck is a governance the organization will learn to avoid.
Data contracts between systems. A data contract is an explicit agreement at the interface between two systems: what schema the data has, what each field means, and what is guaranteed about its quality and its frequency. When the producer and the consumer agree on a contract, they decouple: each can evolve internally without breaking the other, as long as it respects what was agreed at the interface. It is the same standardized plug, now applied to data: you change the appliance without redoing the wiring. With the record separated from the stream and each domain owning its data, the other half remains: quality where it matters, progressive rigor, and traceability for analytics and for AI. It closes in the next note.