The Foundation Decision
Most governance programmes are solving the wrong problem first
This is the first essay in a four-part series on federated metadata governance. The series argues that governance is only as strong as the sequence beneath it: governed source systems, a maintained translation layer between domain representations, and governance architecture designed for agents rather than analysts. Each layer depends on the one beneath it.
We have convinced ourselves that comprehensive cataloging is the answer to data complexity. But consider what actually happens: you deploy an enterprise catalog, wire up thousands of assets, and six months later analysts are still asking colleagues for the right revenue table. An analyst sees twelve similarly named tables. All look plausible. None say which one the CFO signs off on. So she does what she has always done: messages the one engineer she trusts.
The catalog is not part of the story.
If a human analyst is confused by twelve tables, an automated agent is effectively blinded by them.
Throughout this series, an agent means any automated system that reads data, makes a decision, and acts on it without requiring a human to approve each step. Agents are not passive consumers. Every action they take writes back into the systems that will feed their next decision. The reason that distinction matters is that humans who encounter bad data can pause, question, and correct. Agents cannot. They act, at whatever speed the workflow demands, on whatever the data says. The stakes of getting the foundation wrong are not bad dashboards. They are operational systems acting on broken data, at scale, before anyone notices.
Catalog failures are rarely catalog design problems. They are symptoms of a deeper failure: the operational systems feeding the catalog were never governed consistently at their source, so even the most thoughtfully designed catalog ends up faithfully describing an ungoverned reality. The answer is a foundation decision most organisations are avoiding, and a sequencing discipline most governance programmes are not designed to deliver.
The Decision Nobody Wants to Own
Two certified dashboards show different revenue figures for the same period. Both draw from governed sources, both pass quality checks. The difference traces back to how customer status is encoded: the CRM defines active customers by last engagement date, billing by current contract status. Each system is internally correct. But nobody ever made the decision about which definition the coordination layer should stand on, so it stands on both simultaneously, producing outcomes the business cannot reconcile.
The coordination layer is the shared infrastructure that connects source systems to the decisions and analytics built on top of them. Most governance investment targets that layer. It coordinates and connects. Source governance targets the systems themselves, before they connect to anything. This is what source governance is actually for, and this is what most organisations are not doing when they invest in coordination governance instead.
Coordination governance is additive. You build a layer on top of what exists, create standards, establish a federated governance team. Existing systems continue as before. Nobody loses authority, nobody’s release schedule changes.
Source governance is different in kind. Treating data accuracy as a release requirement, the same gate that must be cleared before any software is allowed to go live, means telling the teams that own those systems that their definition of done has changed. It means someone with system authority owning the consequences of source data failures rather than delegating them to a governance council with no authority over the systems producing the problem.
Governance programmes are designed to coordinate and influence. Source governance requires authority. The gap between them is where most federation attempts quietly stall.
What Avoidance Produces
Coordination infrastructure built on ungoverned source systems looks elegant. Standards are published, quality gates pass. And then, months into operation, outcomes do not match what the business expects. The investigation traces backwards through compliant-looking operations to the same conclusion: the gate was enforcing a definition that two source systems encoded differently.
The sophistication of the layer above did not compensate for the unreliability below. It obscured it. The more confident the governance architecture, the harder the failure is to locate, because every layer above the source was doing exactly what it was designed to do.
Authoritative incoherence: a system that is internally consistent, auditable, and wrong about what the business needs it to mean.
Making data quality a release requirement for an ERP or CRM means the team that owns that system carries a new engineering obligation, often set by a function they do not report to. Most organisations choose to work around that rather than through it. The cost accumulates invisibly until a decision fails in a way that traces back to the source.
Knowing What Is Worth Governing
The source governance impulse tends to make the same mistake as the comprehensive cataloging impulse: treating everything as equally important. The cost of governing a source system to an engineering standard is real. It changes release processes, adds obligation to system owners, requires ongoing maintenance. Not all data carries equal risk when it fails at the source, and the category it falls into determines what level of governance it warrants.
Three distinct functions carry different obligations.
Operational data, the schemas and identifiers builders depend on, requires accuracy and stability but can often be governed through lighter mechanisms.
Compliance and regulatory data requires traceability and auditability regardless of query frequency, because the liability exists whether or not anyone is actively querying it.
Consumption-ready data, the refined datasets feeding decisions, requires the highest investment because failures propagate into the widest range of downstream outcomes.
The practical test: if a source system changed this element tomorrow without notifying anyone, which downstream decisions would fail silently before anyone noticed? Those are the elements that warrant source governance at engineering standard. Everything else can be governed with lighter mechanisms, or left in the operational systems where it already lives.
The paradox of comprehensive cataloging resolves when organisations stop trying to make everything findable and start making the right things findable in the right ways for the right people. Source governance is what makes that resolution real rather than rhetorical.
What This Demands Organisationally
The foundation decision requires naming who owns source system data quality as an engineering responsibility, with genuine authority over the systems they are accountable for and the ability to set release requirements that teams building on those systems must meet. When that decision is made, investigations that took months begin resolving in days, data products get reused rather than rebuilt, and programmes launch on foundations that were prepared rather than assumed. For anyone responsible for a governance programme or a data budget, this is the decision that determines whether everything built on top of it holds.
When your most critical data-dependent system produces an outcome the business does not recognise, can you name the person with authority to change the source system behaviour that caused it? Not the governance team. Not the data quality programme. A person, with system authority, who owns the consequence.
If the answer is no, the foundation decision has not been made.
Has your organisation made the foundation decision explicitly, or has it been assumed to sit somewhere between the system owner’s remit and the data team’s mandate without either owning it directly? That gap is where most federation programmes quietly lose their footing. I would like to hear what you are finding.
The next essay asks what happens once the foundation is solid, and why building shared meaning across domains is more demanding than most governance programmes expect, and more valuable when it is done well.
Further reading
The organisational authority question underlying this essay is developed in two earlier pieces: The Authority Crisis in Data Governance examines what happens when governance decisions are embedded in code without clear human accountability, and The CIO Should Eat the CDO argues that system integrity, not data quality policy, is the real governance mandate in an agentic world.
An honest endnote
The argument for governing specific data elements whose failure cascades into unrecoverable outcomes is directionally right, but identifying those elements in practice is harder than the framework suggests. Which elements are genuinely load-bearing depends on the agent workflows an organisation is running or planning to run, and those are rarely fully mapped before governance decisions need to be made. The sequencing argument is sound. What minimum viable source governance looks like for organisations starting from a poorly governed baseline is a question this essay leaves open.