The model is not the problem. The formal governance architecture is the one organisations design. The real one is the one they measure, escalate, and reward. And the real one was already running before anyone wrote the first ownership policy.

The incentive structure, meaning what the organisation counts, escalates, and rewards, was never designed to make ownership rational. By the time the first data owner was named, the measurement system was already answering a different question entirely. You have probably seen this. The question is whether you have seen why.

Subscribe now

What the Wrong Question Produces

When the team responsible for a set of data changes a status code, or any definition the teams depending on them have built on, to reflect how their operational process now works, the change is internally correct and takes an afternoon. Every team that built on the previous definition absorbs the consequence without warning. The reconciliation takes weeks. The data ownership model says this team is accountable for the cost their change created. The measurement system says they had a productive afternoon. Only one of those two things shaped the decision. By every metric they are measured on, the owner looks productive. The teams doing the reconciliation work look like they are struggling with execution.

This is the entropy tax: the cost an organisation pays when local decisions export disorder to the teams depending on what that owner produces. The mechanism has three properties that make it structurally persistent. The cost is invisible at the source: the owner who made the change does not experience the consequence, so there is no signal to change the behaviour. The cost is distributed at the destination: it lands across multiple teams, disguised as separate execution problems that nobody connects to a common origin. And the cost is attributed nowhere: the measurement system never traces reconciliation work back to the decision that caused it. Together, these three properties mean the problem produces no corrective signal at any point in the system.

The data owner is not failing to own. The incentive structure has made genuine ownership economically irrational.

A data owner who coordinates a change across the teams depending on their data is not making a principled choice. They are making the only irrational one the measurement system offers. Their coordination effort is invisible on the performance review. The reconciliation cost they prevented is equally invisible: it never happened, so it cannot be counted. The measurement system rewards the owner who ships fast and penalises nothing. The teams absorbing the cost have every reason to want the situation addressed and no leverage to require it.

Leadership working from this system will consistently make the wrong call: investing in owners whose performance looks strong because their costs land elsewhere, and pressuring the teams absorbing those costs as though the friction between them were an execution problem rather than a design signal.

What the Measurement System Would Need to Look Like

The cost-attribution problem does not resolve by naming it. It resolves by changing what the measurement system makes visible. That requires asking a question most ownership programmes never ask: not how to fix what they have, but what they would have measured if they had known, from the start, that the measurement system was a governance decision.

Output metrics ask what happened inside a team: schemas changed, pipelines run, quality scores within the domain. These answer the wrong question. The question ownership is supposed to answer is: can the teams depending on this owner’s data act on it without first verifying it with them? Verification-as-proxy is the right boundary test because it measures the cost the ownership model was designed to eliminate, not the activity it was designed to encourage.

Output metrics describe what happened inside the team. Outcome metrics describe whether ownership is working at the boundary.

Two further outcome metrics sharpen the picture. Whether data quality incidents are resolved by the team that caused them, or absorbed by the teams depending on them. And the full loop from a change being made, to the owner becoming aware of its impact on others, to that impact being resolved.

That last metric is two numbers, not one. How quickly the owner becomes aware measures the feedback loop. How quickly the impact is resolved measures accountability. An organisation tracking only the first has visibility without ownership.

Awareness without resolution is not accountability.

Redesigning the measurement system to capture these outcomes requires attributing cost to teams that currently look like high performers. The team whose status code change sat in someone else’s backlog for three weeks needs to see that cost as theirs. That attribution will be resisted. It is also precisely the point: the measurement system cannot make ownership rational until it measures at the boundary between teams, not the performance inside them.

How Measurement Changes What Ownership Means

The measurement system is the most legible component of the incentive structure: when it changes what is visible, the calculation changes before any formal policy is updated.

Introducing outcome metrics and accountability at the same moment conflates two different problems: making the cost visible and deciding who bears it. The most effective way to introduce outcome metrics is not simultaneous with accountability. First, make visible what an owner’s decisions cost the teams depending on them, without attaching performance consequences. An owner who sees that their change sat in another team’s backlog for three weeks has received a signal they did not have before. That signal changes the calculation. Visibility removes the plausible deniability that made unilateral change rational: an owner who has seen the signal cannot make the next decision the same way.

Second, once the connection between a decision and its cost is legible, accountability is attached: the cost to others becomes part of the owner’s performance picture, and the escalation pattern and reward structure follow from the same logic.

The ownership model sets the intention. The incentive structure determines whether that intention is rational to act on. As the measurement system changes what is visible, what ownership means changes with it. Not through policy, but through the calculation an owner makes before the next decision. The definition of good ownership shifts from “my data is clean” to “my data is reliable for the teams depending on it.”

Making cost visible before attaching consequences is a partial answer to the political resistance this redesign will face. It is not a complete one. The harder question is enforcement.

The decision of when to move from visibility to accountability requires someone with the authority to define what reliable ownership means for this organisation. Most organisations do not have a named role for that. Its absence is itself a measurement system design failure: the incentive structure was never designed to include the authority to enforce it. The role is not a title. It is the function of deciding, under delivery pressure, that the boundary measurement holds. Without it, the measurement system has visibility and no consequence, which is the same problem restated at a higher level.

The Design Question That Was Always There

Data ownership was always a design decision about measurement: the model describes who is accountable, but whether that accountability is rational to honour depends on what the measurement system rewards.

Fixing the model without redesigning the measurement system is writing a governance policy over an architecture that will continue governing regardless.

The question to ask before the next data ownership review is not what the model needs. It is what the measurement system is currently rewarding. If the answer is local delivery and local quality, you already know what the ownership model is operating against. The answer to what you would have measured is the same as the answer to what you should redesign toward.

An incentive structure that rewards local performance will always produce local optimisation, regardless of what the ownership model says about accountability.

Further reading

The Hidden Danger of Success You Can’t Explain: develops the mechanism by which improved boundary metrics may reflect genuine behaviour change or changed reporting, and why telling the difference requires understanding the drivers of the outcome, not just the outcome itself.

The Authority Gradient: develops the enforcement argument this essay points toward. Redesigning the measurement system still requires someone with the authority to hold that redesign when local delivery pressure pushes back.

Naive Federation: Centralisation’s Evil Twin: names the entropy tax mechanism in full and develops what happens when data ownership is distributed across many domains: the measurement argument applies with equal force, but the political difficulty of attributing cross-team cost multiplies with the number of owners.

The Entropy Tax: A New Law of Organizational Physics: develops the cost mechanism this essay identifies as the output of a measurement system that was never asked the outcome question.

Where Data Strategy Actually Lives: examines where data decisions are actually made versus where organisations believe they are made, a companion to this essay’s argument about where governance actually operates.

An honest endnote

This essay argues that data ownership fails because the incentive structure was never designed to make ownership rational, and that fixing it starts with the measurement system: outcome metrics at the boundary, visibility before accountability.

Two open questions remain. The first is infrastructural: boundary metrics require data that most organisations are not yet collecting, and building the system that makes cross-team cost legible is a genuine prerequisite, not an implementation detail. Making cost visible before attaching consequences is a partial answer to the political will problem, but it does not answer the data collection problem. The second is epistemological: outcome metrics at the boundary may themselves create new blind spots, because you can only measure what you already know to look for. The right posture is to treat the measurement system as a hypothesis to be tested and revised, not a solution to be declared complete.

This is written close to the work. If your data owners are doing exactly what the incentive structure rewards and still not producing the outcomes the ownership model promised, the gap between those two things is the design question that was never asked.

A domain team is three days from a release. The shared schema does not fit the timeline. The governance function pushes back. It loses. Not because the framework was wrong. Because the authority to enforce it was never actually designed.

Authority is treated as a cultural property in most organisations. You earn it by building credibility, by accumulating trust. That account is not wrong, but it is incomplete in a damaging way. Authority that depends on relationship disappears when the stakes are highest. What an organisation needs when a governance standard collides with a delivery deadline is structural authority: the kind built into the governance architecture itself, not the goodwill of its participants. The contracts can be coherent, the standards well-formed, the framework rigorous, and the architecture still fails when friction arrives and nothing can require it be honoured.

Subscribe now

Three Kinds of Authority, One That Matters

Organisations use the word authority to mean three different things. Only one changes behaviour under pressure.

• The first is definitional authority: the standing to say what a standard is, write the contract, define the schema. Most governance functions have this. Documents get written, standards published.

• The second is advisory authority: the standing to be consulted when decisions touch shared standards, honoured when convenient and skipped when not.

• The third is enforcement authority: the standing to enforce a standard even when a delivery timeline is at stake. This is the only kind that changes behaviour under pressure. And it is the kind almost no governance function actually has.

The gap between definitional and enforcement authority is where most governance investment disappears. Under pressure, every domain makes the same calculation: the cost of honouring the standard is immediate; the cost of violating it is not.

The Gradient

The more useful frame is not binary, authority or no authority, but gradient: a designed sequence of escalation points that makes the cost of violating a standard visible and progressive, without requiring a block-or-release decision at every boundary.

The reason enforcement authority is so rarely designed as a gradient is that it feels like a blunt instrument: authority that can block a release seems at odds with domain autonomy. The instinctive resolution is to soften it into something advisory. That feels like a reasonable trade-off. It is the point at which the governance architecture stops working. The binary framing, enforce or advise, collapses the gradient into a single high-stakes moment. The gradient distributes that moment across a sequence of smaller, proportional ones.

Where binary authority structures exist, they typically fail for two reasons that are rarely named.

• The first is proximity: an architecture review board or governance committee is usually too far from the operational context to assess what violating a standard actually costs in a specific situation. It holds the authority but not the knowledge.

• The second is speed: the lead time to a committee decision rarely fits inside a delivery timeline. A team under deadline pressure will skip a process that cannot run at delivery speed.

The gradient addresses both: it makes the cost visible at the point where the decision is made, close to the work and within the timeline, rather than reviewed by a committee after the pressure has already forced a conclusion.

The structural gradient locates the insight in the architecture rather than the psychology. It starts with transparency: domains can see what they are diverging from and what that divergence costs downstream. It moves through friction: divergence requires explicit acknowledgement, a named decision-maker, a documented rationale. It reaches a hard stop only where the divergence would create a consequence the organisation cannot absorb without leadership engagement.

Think of a building code. An architect designing within it works without friction. One who wants to deviate from a structural requirement enters a variance process with explicit sign-off and recorded liability. A deviation that would make the building unsafe does not proceed regardless of the client’s timeline. The analogy has one limit: building codes are enforced by an external authority with no stake in the delivery timeline. But the mechanism transfers: graduated consequence, proportional to risk, with a stop that holds. Without it, the code is a suggestion.

Most data governance architectures publish the building code. They do not design the variance process or the structural stop.

What Designing It Requires

Three decisions most organisations either avoid or resolve by default. The first, and the one that makes the other two possible, is leadership endorsement. When a governance function enforces a standard that delays a release, the domain’s leadership will escalate. The governance architecture needs to be a leadership commitment before it is an operational one. Without that backing, naming a role and designing friction are both meaningless: the gradient holds in calm weather and bends in storms.

The second is naming who holds enforcement authority. When domain A wants to change a schema domain B depends on, and B objects, who decides? Without a named role and a response time, the decision defaults to whoever has the most delivery pressure.

The third is designing the friction itself, not just the policy. A process that requires a domain team to leave their tooling, file a separate ticket, and wait for committee review will be skipped under pressure. Friction should be proportional to risk and fast enough to run inside a delivery cycle: present enough to make the decision visible, light enough that honouring the standard stays the easier path. A process that cannot be completed within the timeline it is supposed to govern will be skipped, not because teams are unwilling, but because the governance architecture was designed for a different tempo than the work it is governing.

Authority in Calm Weather

The test is simple: what happens to the governance architecture when a domain team is under serious delivery pressure? If it holds in calm weather and bends in storms, the organisation does not have a governance architecture. It has a documented intention.

Authority that exists only when nobody is under pressure is not authority at all. It is a policy document with a governance team’s name on it.

Domain autonomy is not a property of the org chart. It is a property of the contracts the domain has agreed to honour and the gradient that makes those contracts enforceable under pressure. A domain without that gradient is not autonomous. It is ungoverned, and the consequences propagate to every domain that depends on it. This is why federation without an authority gradient does not produce distributed governance: it produces distributed disorder, with the entropy tax accumulating silently at every boundary where enforcement was never designed.

The authority gradient is not a constraint on federation. It is the condition that makes federation coherent rather than merely distributed.

The question is not who has the authority to define the standard. It is who has the authority to enforce it when honouring it is inconvenient. Design that, and you have a governance architecture. Leave it undefined, and you have a very well-written document.

Further reading

Naive Federation: Centralisation’s Evil Twin: names the broader failure mode of distribution without the conditions that make it principled, and develops the coordination debt the authority gradient is designed to interrupt.

The Data Platform Was Never a Place: establishes what a platform actually is before the question of governing it across distributed domains can be answered.

The Accountability Decision: takes up who holds accountability for cross-domain quality when ownership is distributed.

The Entropy Tax: develops the mechanism by which local optimisation exports disorder to the broader system.

An honest endnote

This essay argues that enforcement authority needs to be designed, not assumed, and that the gradient is the mechanism that makes it proportional rather than blunt.

Three open questions remain. The first is sequencing: how an organisation builds the gradient from a poorly governed baseline, where authority structures are contested and leadership has not yet committed. The second is human: structural authority creates the conditions for a No to be said, but not the willingness to say it. A person who has learned that using enforcement authority is career-limiting will not use it regardless of what the architecture permits. The gradient is a necessary condition, not a sufficient one. The third is distinction: how to tell legitimate variation from avoidance, where a domain has a genuine operational reason to deviate rather than a delivery pressure one. The gradient makes that decision visible. Designing for the distinction itself is harder.

The gradient is also only enforceable if the measurement system has already been designed to make violations visible. Authority without visibility is a structural stop with no signal to trigger it. That prior design question is where the companion essay on measurement begins.

This is written close to the work. If the authority structures in your organisation look different from what this essay describes, or if the gradient argument breaks down in a context this piece did not anticipate, that is where the next version of the argument begins.

This second series goes deeper into that ground. It is written for the people who sit at the intersection of technical architecture, organisational authority, and strategic investment: those who have to make governance work rather than merely describe it. The argument running through all four essays is that governance is only as strong as the sequence beneath it.

Foundation, then translation, then the honest funding of coordination obligations, then governance architecture designed for the environment agents actually operate in. In that order, or not at all.

Subscribe now

The Four Essays

The Foundation Decision — Most governance programmes are solving the wrong problem first

Source governance is an engineering release requirement, not a data quality policy. Most organisations treat it as a coordination problem and discover too late that they have built sophisticated governance architecture on foundations nobody controls. The cost has a name: authoritative incoherence, a system that is internally consistent, auditable, and wrong about what the business needs it to mean.

The Translation Investment — The hidden cost of domains that cannot agree on what words mean

Different domains hold legitimately different representations of the same reality, and no amount of enterprise ontology work resolves that. The goal is not a unified dictionary but a maintained translation layer. A platform is not a place where data lives. It is a logical construction of shared contracts and semantics that governs how data is used wherever it originates.

The Cost of Distribution — Distributed ownership hides its costs until the bill arrives

The expertise obligation, the versioning obligation, and the standards obligation tend to persist as federation matures rather than resolve. They are permanent design costs to be funded deliberately. Beneath all three runs a foundational tax: the price of building coordination infrastructure on sources that were never governed to be trustworthy.

The Accountability Decision — Agents do not fail loudly. That is precisely the problem.

When agents become the primary consumers of federated metadata, every coordination cost becomes an operational risk. Accountability must move from decisions to architecture: whoever designs the boundaries within which agents operate owns every decision those boundaries produce.

Where to Start

The essays can be read independently. Each one stands on its own argument. If you want to understand where this series began and what the first series established about cataloging, coordination, and the original costs of federation, the original three essays are the natural starting point before this one.

A Learning Journey

The original series published its third essay as explicit exploration rather than conclusion. This second series is where that iteration landed, with more confidence on the sequencing argument and more honesty about what remains open. The foundation argument does not fully resolve what minimum viable source governance looks like from a poorly governed baseline. The accountability argument names what the learning loop must do without fully specifying what it looks like in practice. These are not evasions. They are the questions where the thinking needs to keep developing. If you are working through any of them in your own organisation, I would genuinely like to hear what you are finding.

Additional Reading

The authority question: The Authority Crisis in Data Governance, The CIO Should Eat the CDO, The Logic Has to Stand on Something.

The platform and meaning arguments: The Data Platform Was Never a Place, Where Meaning Comes From.

The AI governance angle: The Governance Paradox: Human Oversight at Machine Speed.

The organisational cost of local optimisation exporting disorder to the broader system: The Entropy Tax: A New Law of Organizational Physics.

The original federated metadata series, When Everything Becomes Findable, The Metadata Coordination Problem, and What Federation Actually Costs, is where these arguments began. This series is where they became more certain.

An honest endnote

The sequencing argument this series makes, foundation before translation, translation before the honest funding of coordination obligations, all three before agents, is presented with more confidence than any individual organisation’s situation may warrant. The right starting point depends on where you are: an organisation with a poorly governed baseline faces a different set of first moves than one with stable source systems already in place. The essays argue for the sequence as a structural dependency, not as a universal implementation plan. What minimum viable looks like at each layer, and how to make progress when the foundation is still being established while the coordination layer is already in use, are questions the series identifies but does not fully resolve.

The series has also chosen to stay at the governance and organisational authority layer rather than the agentic architecture layer. Others are going considerably deeper into the operational design of agent networks. ’s work on agentic mesh at agenticmesh.substack.com is worth reading for anyone who wants to follow that thread further. That is where the most important adjacent work is being done.

An agent managing maintenance schedules does not produce a report for a human to review. It reads asset status, applies priority logic, and writes updated work orders back into the operational system, continuously, at whatever speed the workflow demands. For several weeks, everything reports green. Work orders are being processed. Queues are clearing. And then field teams begin raising queries: jobs are being assigned to the wrong locations, urgent tasks are being deprioritised, records the agent is writing back are inconsistent with what the source system expected to receive. The investigation traces backwards through weeks of compliant-looking operations. The governance gate passed at every step. The failure was not in the agent. It was in an identifier format that had drifted between two source systems, silently, in a change that passed its own release process without triggering any downstream dependency check.

The specific danger is not that the system failed loudly. It is that it continued to succeed quietly, producing outcomes the business did not recognise as failures until the damage had already compounded. This is silent breakage: governance gates passing, dashboards reporting green, and operational reality quietly diverging from what the business expects.

The previous essay closed with two tests: can you name the person with authority to enforce a shared standard, and can you name the person with authority to change a source system the coordination layer cannot reconcile. Those tests remain necessary. In an agentic environment they are no longer sufficient. Even a named person with genuine authority cannot govern through decision review at machine speed. The accountability model itself must change shape.

Most organisations deploying agentic AI are applying the governance architecture they already have. The intention is sound. The architecture is the wrong shape.

Subscribe now

The Feedback Loop Nobody Has Accounted For

Agents cross domain boundaries in sequence, consuming data from each system they pass through and writing outputs back into the same systems that fed their decisions. That traversal pattern is what makes every coordination cost from the previous essays directly operational rather than merely structural.

In a human-centric system, a metadata failure surfaces as an analytical problem: a dashboard shows an unexpected number, an analyst investigates, a ticket is raised. The failure is visible and correctable before it propagates. In an agentic system, the same failure is operationally real and structurally invisible. No alert fires. The governance gate passed. The agent continues acting on the broken state until a human notices that outcomes have stopped making sense.

The deeper problem is what happens in the interval. Agents do not only consume data; they produce it. Every action writes back into the operational systems that feed the next decision. An ungoverned source does not merely produce unreliable inputs. It produces what the first essay called authoritative incoherence, now running not at the level of a dashboard but through every decision the agent makes. It receives unreliable outputs that make the original problem progressively harder to locate, inside systems that are all reporting green.

The first feedback loop runs from agent action back into source systems, compounding the original problem invisibly. The second loop, the one most organisations have not built, runs from agent behaviour back into the governance architecture itself: learning from what agents reveal about where the boundaries were wrong, and adjusting them before the next cycle compounds the gap.

Automated monitoring alone cannot resolve a problem that is architecturally invisible by design.

Why Transactional Accountability Is the Wrong Shape

The instinct when deploying agentic systems is to extend existing governance: periodic output reviews, escalation paths, automated monitoring when volume exceeds human capacity. Automated monitoring detects when outputs fall outside expected ranges. It cannot detect the silent breakage pattern, where outputs look correct because no validation rule fired but are operationally wrong because the metadata they were based on changed without notification.

Transactional accountability also builds in an escape route. A reviewer can say the decision looked correct at the time. When something goes wrong, accountability distributes across the chain of approvals until it dissolves. In an agentic system operating at machine speed, that question becomes unanswerable before the failure has finished compounding.

The governance architecture that works for an agentic environment moves accountability from decisions to architecture. It asks not whether the agent made the right decision but whether the organisation built a system whose boundaries make the right decisions likely and the wrong ones detectable.

In practice this means the person who designed the boundaries of what the agent can and cannot do is accountable for every outcome those boundaries produce, in the same way that an architect is accountable for a building’s structural safety regardless of who laid the individual bricks. Architectural accountability removes the escape route entirely. That is precisely why most organisations are reluctant to adopt it and precisely why agentic environments demand it.

What Governance Architecture Designed for Agents Actually Requires

The first requirement is risk-differentiated source governance. The identifiers agents use to traverse systems, the definitions they use to classify and route, the thresholds they use to decide whether to act or escalate: these require source governance applied with the rigour of uptime and security requirements. An agent acting on a drifted identifier does not flag the inconsistency for human review. It acts, at scale, before the inconsistency is visible. The governance investment concentrates where agent action amplifies the consequence.

The second requirement is translation layer integrity maintained under agentic load. Where the previous essay described the versioning and standards obligations as permanent costs, under agentic load those obligations acquire operational urgency. The translation layer is not maintaining mappings between stable representations. It is continuously negotiating between domains whose meaning is always local and contextual. Agents have no capacity to recognise when that negotiation has broken down. A translation that drifts without notification does not produce a contested report. It produces a silent operational failure that compounds through the feedback loop described above.

The third requirement is a learning loop that treats agent behaviour as a governance signal rather than an operational outcome to be managed. Upfront design cannot anticipate every inconsistency agents will surface when traversing real operational systems at real speed. Think of it as a circuit breaker: when agent behaviour signals that the foundation or translation layer has drifted beyond a reliable threshold, the architecture should pause agent write-access rather than allow the compounding to continue while the fault is located and fixed. The organisations that navigate this well treat those surfaced inconsistencies as information about where the governance architecture needs to mature, feeding back into source governance and translation layer maintenance continuously. Without this loop, the architecture drifts from the operational reality it governs until a failure makes the gap visible.

What This Gives the Organisation

An organisation that has made the foundation decision, invested in the translation layer as a service, and funded the coordination obligations honestly gains something specific: failures become detectable before they compound, locatable when they occur, and correctable without tracing backwards through months of compliant-looking operations. For those responsible for deploying or governing agentic capability, that is the difference between a programme that builds confidence over time and one that accumulates anxiety.

Most organisations extending existing governance to cover agents are building toward authoritative incoherence, not at the level of a single source system, but across the full operational stack agents traverse. The sequence this series has argued for is a structural precondition, not a governance improvement programme.

Foundation, then translation, then the honest funding of coordination obligations, then governance architecture designed for the environment agents actually operate in. In that order, or not at all.

Where in your organisation is agent-driven automation already writing back into operational systems, or will be within the next year? What happens to everything downstream if what it writes is wrong for thirty days before anyone notices? That question tends to locate the governance gap more precisely than any maturity framework. I would like to hear what you are finding.

Further reading

The architectural accountability argument draws on The Governance Paradox: Human Oversight at Machine Speed, which examines what governance looks like when decision volume exceeds human review capacity. The platform capability argument is developed in The Data Platform Was Never a Place. Both approach the same underlying question from different angles: what does it mean to govern systems that operate faster than human oversight can follow. The learning loop argument in this essay, that agent behaviour must feed back into governance architecture continuously, connects to the feedback-first organisational design argued in The Entropy Tax: A New Law of Organizational Physics.

An honest endnote

The essay argues for a learning loop that treats agent behaviour as a governance signal, but does not specify what that loop looks like in practice: who owns it, what signals it processes, how frequently it runs, and how its outputs feed back into the source governance and translation layer decisions made in the first two essays, and how it keeps pace with meaning that is always shifting rather than drifting from a stable state. That is a genuine gap. Others are going considerably deeper into agentic architecture and the operational design of agent networks than this series does. Eric Broda’s work on agentic mesh at agenticmesh.substack.com is worth reading for anyone who wants to follow that thread further. This series has chosen to stay at the governance and organisational authority layer rather than the agentic architecture layer, and that is a deliberate boundary, not an oversight. Most organisations deploying agentic systems have not yet designed the feedback loop at all, let alone designed it well. That is where the most important work remains to be done.

Distributed ownership does not distribute the cost of coordination. It hides it, until the bill arrives in a form nobody expected and nobody budgeted for.

Consider what happens when an engineering team spends three months improving how they catalog infrastructure specifications. They consolidate redundant fields, update identifier formats, and streamline their internal workflow. Entirely reasonable within their domain. Two weeks after the changes go live, a compliance report starts showing null values in critical fields. A maintenance scheduling system stops assigning work orders because the identifier format it expects no longer matches what engineering produces. An analytics pipeline built on the previous field names returns empty results. Engineering optimised their catalog. Three other systems broke. Nobody in engineering knew those systems existed. Each system was internally consistent, auditable, and wrong about what the others needed it to mean.

Most federated governance programmes, where each business domain owns and manages its own data rather than a central team managing it for everyone, treat this as an implementation problem: better tooling, more mature processes, clearer documentation. That framing works in centralised systems, where coordination costs genuinely reduce as architecture matures. Distributed ownership is structurally different. The blind spots above are not a function of immaturity. They are a function of the architecture: when ownership is distributed, no single team has visibility into all cross-boundary consequences of their decisions, and maturity alone does not close that gap.

For most organisations, these costs tend to persist as federation matures rather than resolve. The organisations that navigate federation successfully are not the ones that eliminate these costs but the ones that stop expecting to eliminate them and start funding them deliberately.

Subscribe now

Three Obligations Worth Naming

The expertise obligation is the permanent cost of ensuring domain teams can exercise judgment across boundaries, not just within them. Semantic debt, the cost of leaving meaning undesigned for across domain boundaries, does not maintain itself. The expertise obligation is what the organisation pays to keep that debt from compounding silently. Domain teams will always optimise for their own operational context first. The engineering scenario above is not a failure of awareness. It is the predictable consequence of distributing ownership without distributing visibility into cross-boundary consequences. The smarter each domain becomes at optimising locally, the more profound the organisation’s collective blindness grows.

Federated metadata expertise is not a stable state to achieve. The cross-boundary consequences of domain decisions shift continuously, because meaning in each domain is always local and contextual, so the investment is not in reaching shared understanding but in sustaining the conditions under which that understanding can be continuously refreshed.

The versioning obligation is the permanent cost of managing independent evolution. Each domain versions on its own timeline for legitimate operational reasons: engineering moves when internal workflow requires it, compliance stays on the previous version because regulatory mappings take months to validate, analytics runs a custom extension neither domain tracks. Every schema change, the restructuring of how a system organises and names its data, in any domain becomes a coordination event for every domain that depends on it. This is not a function of immature change management. It is a consequence of responsibility for downstream dependencies being distributed rather than central.

Resolving this requires ongoing investment in two directions: the translation-as-service layer described in the second essay, capable of handling version multiplicity, and governance mechanisms that coordinate migrations before they propagate as silent breakages across systems that never knew they were connected.

The standards obligation reveals something counterintuitive about federation.

Federation requires more central discipline, not less. It simply requires less central execution. You can distribute the work. You cannot distribute the logic of what makes the work coherent.

Standards, shared identifiers, and synchronisation protocols are what make federated systems coherent rather than merely distributed. Most coordination functions lack the formal authority to enforce what they define. Strengthening advisory governance through more meetings or better documentation does not stop drift, because domains under operational pressure will consistently deprioritise recommendations in favour of local efficiency. Only binding authority changes that calculus. Standards drift silently when authority is advisory, and the gap between what standards say and what systems produce grows invisibly until a decision built on top of it fails in a way that traces back to a standard nobody enforced.

The Foundation Beneath the Obligations

Running beneath all three obligations is a prior question: were the source systems being federated governed consistently at their origin before the federation was built on top of them?

When they were not, each obligation compounds on an unstable foundation. The coordination layer, the shared infrastructure connecting source systems to downstream decisions, certifies unreliability as compliant, making failures invisible at the point where they occur. Expertise gaps become harder to close, versioning conflicts impossible to resolve, and standards failures unlocatable, because coordination authority sits above source systems nobody with real authority ever committed to governing reliably.

This is the foundational tax: the price an organisation pays for building coordination infrastructure on sources that were never governed to be trustworthy. Federation can redistribute the ownership of a problem. It cannot redistribute the problem away.

Two Tests Worth Applying

Before declaring federated governance mature enough to trust with consequential decisions, two tests are worth applying honestly. The reason these tests require a name rather than a committee is specific: collective accountability distributes the consequence of failure in a way that makes it structurally impossible to act quickly when a source system breaks.

The coordination test: can you name the person with authority to enforce a shared identifier standard when a domain resists changing it? Not the governance team, not the standards committee. An actual person with the standing to require compliance and the accountability to own the consequences when compliance fails.

The foundation test: can you name the person with authority to change a source system validation rule when it is producing data the coordination layer cannot reconcile? Not a team or a council. An actual person, with genuine authority over the source system, who can act before the next cycle of decisions compounds the problem.

A council can point to the right meetings held and the right documents approved. A named individual cannot. That is precisely why naming matters. For anyone holding a governance budget or a programme mandate, these two tests are the fastest way to find out whether the investment is standing on prepared ground or assumed ground.

If you can answer the first but not the second, you have coordination infrastructure built on a foundation nobody controls. The bridges may be sound. What they connect may not be.

What obligations are you finding in your own federation programmes? Where has the expertise gap, the versioning complexity, or the standards drift surfaced, and how has your organisation chosen to fund or avoid the cost? I would like to hear what you are finding.

The fourth essay asks what changes when agents become the primary consumers of federated metadata, and why accountability must move from decisions to architecture.

Further reading

The three taxes named in this essay were first introduced in What Federation Actually Costs. The authority question underlying the standards obligation is examined in The Authority Crisis in Data Governance and developed further in The Logic Has to Stand on Something. The organisational cost of local optimisation exporting disorder to the broader system, the same mechanism this essay describes at the governance layer, is examined from a leadership and boundary design perspective in The Entropy Tax: A New Law of Organizational Physics.

An honest endnote

The essay argues that the three obligations must be funded as permanent design costs. It does not address what minimum viable funding looks like for each, or how organisations should prioritise between them when resources are constrained. In practice, the standards obligation tends to be most urgent because ungoverned standards drift faster than expertise gaps widen or versioning conflicts accumulate. But the right sequencing depends on where an organisation’s federation is in its maturity, and naming a universal sequence would give false precision to a question that requires contextual judgment.

Every large organisation has at least one report that always needs a footnote. Finance and operations look at the same underlying data and produce different numbers. The footnote explains which version of the truth the report reflects, who calculated it, and why the other number is also technically correct. It has existed for years. Nobody has removed it because nobody has resolved what it represents.

Once source systems are governed to a consistent standard, organisations face exactly this problem. The data flowing through the coordination layer is technically trustworthy. Identifiers are stable, quality gates stand on solid ground. And yet cross-domain decisions still produce outcomes that different parts of the organisation contest.

This is not a source governance failure. It is a translation failure. And most organisations have been trying to solve it with the wrong tool.

Subscribe now

The Dictionary Trap

The instinct when meaning diverges is to converge it: define the canonical version, build the enterprise ontology, get everyone to agree before building anything on top. In bounded, single-domain systems that is sound discipline. The problem is that the instinct tends to break down when multiple domains hold legitimately different operational representations of the same reality, which is the common condition of any organisation operating at scale across distributed systems.

A semantic layer or ontology is the architecture that defines what words mean across systems: what a customer is, what a product is, so that different parts of the organisation can use the same data without having different conversations about what it refers to. The problem is not that organisations build them. It is that they treat them as a precondition rather than an outcome. Something to be agreed before the operational work that would make them meaningful has been done.

Consider a bridge asset. Its specifications live in engineering tools, its inspection history in compliance systems, its risk metrics in data catalogs. Three legitimate perspectives on the same physical object, each internally coherent, each serving a different operational purpose, and each encoding that purpose in the structure of the system itself, not just in the labels it uses. Contracts, service, and finance each understand a customer differently, through legal obligations, active engagements, and recognised revenue. These are not competing answers to the same question. They are correct answers to different questions, shaped by different operational realities.

The result of forcing premature convergence is either paralysis, as the governance process consumes the programme, or a canonical definition designed to offend nobody and serve nobody well.

The goal is not a unified dictionary. It is a maintained translation layer that makes the differences between domain representations explicit, maps the boundaries between them, and is honest about what is preserved in each translation and what is lost.

What Semantic Debt Actually Looks Like

Most organisations carry significant semantic debt without naming it as a governance problem. The signs are recognisable: reconciliation projects that never resolve, reports that require permanent footnotes, an informal spreadsheet in a shared drive translating between two systems’ identifiers, maintained by someone who remembers why the discrepancy exists.

The most telling signal is a cross-functional decision that stalls not because the data is missing but because nobody can agree which number to act on. That stall is semantic debt made visible, and it is usually the moment organisations realise the debt has been accumulating for years.

Meaning is always local, temporary, and contextual. Left unmanaged, it does not stay where it was left. As domains evolve independently, definitions drift, and the gap between what a term means in one system and what it means in another widens silently. The condition to design for is not stability but the ability to make good enough decisions when meaning is never fully settled. By the time the debt becomes visible as a governance crisis, the representations are embedded in live systems, and changing what something means carries consequences across every downstream dependency.

Semantic debt is harder to repay than technical debt. The longer it accumulates, the more load-bearing the original representations become. The organisation that defers translation work is not avoiding a cost. It is choosing to pay it later, at a higher rate, under more pressure.

The Platform Is the Translation Layer

A platform is not a place. It is a logical construction: the shared contracts, controls, and semantics that govern how data is created, managed, and used, regardless of where it physically lives. The job of the platform is not to import data to the policy. It is to export policy to the data, wherever that data originates and wherever it is consumed.

When the platform is understood this way, the translation layer is not a separate governance artefact. It is part of what makes those systems a platform in the first place. The shared contracts between domains, the mappings that make different representations interoperable, the standards that govern how meaning is expressed across boundaries: these are the platform. The warehouse is merely infrastructure.

This reframes where the translation layer belongs organisationally. It is a platform capability, owned by whoever is responsible for the logical coherence of the shared contract layer, with authority to require that domains honour those contracts when their internal representations change.

An ontology bolted onto a data pipeline can describe what happened. It is a mirror: useful for reflection, but unable to move anything. A translation layer that is part of the platform’s logical construction participates in what is happening. It is a live contract between systems, not a historical record of how they once agreed to differ.

What a Translation Layer as a Service Requires

In engineering terms, a service is something with an owner who is accountable for keeping it accurate and available. A snapshot is a document produced at a point in time that nobody is responsible for after it is written. The difference between a translation layer that works and one that does not is precisely this distinction.

A snapshot is produced, documented, and left to drift. A service is maintained continuously, with an owner, updated as part of the same release process that changes the domain representations it connects. A simple test: if nobody is alerted when a mapping breaks, you have a snapshot, not a service.

This requires two things most organisations have not established, and they are genuinely distinct. One authority governs what the translation logic should say: what is preserved between domain representations, what is lost, and what constitutes a valid mapping. Another authority governs whether the systems can be made to honour it: the ability to require notification when a domain changes internal representations that affect the translation. Giving one authority without the other produces either standards that cannot be enforced or enforcement that governs the wrong thing. Both are needed, and treating them as the same role is how translation layers become elegant documents that nobody has the standing to make real.

For anyone managing a programme that spans multiple domains, this is where the investment decision sits: not in the modelling exercise, but in the ongoing ownership of the layer that keeps the models honest.

Principled distribution is not a discount on governance. It is a premium on engineering. And the translation layer is where that premium is most honestly paid.

Where is semantic debt most visible in your organisation right now? The reconciliation project that never quite closes, the report that always needs a footnote, the word that means different things on different sides of the room: these are the places where the translation investment would pay back fastest. I would like to hear what you are finding.

The third essay names the ongoing costs of distributed ownership, and shows why those costs are permanent design obligations, not temporary friction.

Further reading

The platform-as-logical-construction argument is developed further in The Data Platform Was Never a Place. The sequencing question, whether meaning must precede data or can emerge from it, is examined in Where Meaning Comes From and The Logic Has to Stand on Something. The concept of bounded contexts, which underlies the argument that different domains should maintain locally coherent definitions rather than being forced into a single shared model, was developed by Eric Evans in Domain-Driven Design.

An honest endnote

The essay argues that translation ownership must be explicit and maintenance treated as ongoing engineering investment. It does not address where the translation function sits organisationally, whether with the platform team, a dedicated data engineering function, or distributed across domain leads. That depends on organisational structure, existing authority relationships, and how the CIO and CDO mandates are divided. What is clear is that wherever it sits, it requires both the authority to define what valid mappings look like and the authority to require domains to honour them when their representations change.

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.

Subscribe now

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.

There is a question underneath most enterprise data transformations that rarely gets asked directly: where does shared meaning come from, and when does it arrive? It is simpler and more consequential than any of those that dominate the conversation.

Subscribe now

The Default Sequence

Most approaches to enterprise data architecture answer that question the same way, even when they use different vocabulary. Define the knowledge model. Agree on what things mean. Then connect data to those definitions and build from there. The ontology, or the semantic layer, or the data catalogue, depending on the decade and the vendor, sits on top of the data pipeline as the layer that makes raw information intelligible.

Meaning precedes movement. Consensus is the precondition for value. This approach assumes that an organisation can be mapped in the abstract before it is engaged in the concrete.

The Inversion

Palantir’s Foundry works from the opposite direction, and that inversion is more significant than it first appears.

The ontology is not designed upfront and then populated with data. It emerges from specific workflows acting upon data that already exists in its operational context. Source systems are connected, objects crystallise from actual transactions, assets, people, and events, and the semantic layer grows from evidence rather than from agreement. The knowledge model and the operational data are not separate things that need to be mapped to each other after the fact. They are the same thing expressed at different levels of abstraction, and meaning becomes negotiable precisely because people can see it in motion rather than having to agree on it in the abstract.

That difference in sequencing changes everything about what transformation actually requires.

Anyone who has tried to get an ent erprise to agree on what a customer means before building anything will recognise the problem. Legal, logistics, and finance hold different and legitimate conceptualisations of the same reality. Those differences are not dialects of one truth waiting to be unified. They are operationally coherent representations that serve different purposes. Asking them to converge before the platform delivers value is asking for consensus as the price of admission.

Foundry sidesteps that price by delivering value before consensus is complete. The object model crystallises from use rather than from committee, which means the political conversation about meaning happens when there is something concrete to look at, when the cost of disagreement is visible and the benefit of alignment is demonstrable. That is a fundamentally different organisational dynamic, and it is probably the deepest reason why Palantir is difficult to reconstruct independently.

Most reconstruction efforts copy the architecture. They cannot easily copy the adoption sequence.

The Risks of Emergence

But the inversion carries its own risks, and being clear about them matters.

Emergent ontologies can crystallise the wrong meaning at scale. Once objects are operational and embedded in live workflows, the cost of changing what something means is far higher than correcting a definition in a modelling tool. Early decisions about representation become load-bearing, not because they were carefully chosen but because they were first. This is semantic debt: meaning that is good enough for now but will require expensive re-mapping later as the organisation’s understanding matures. The organisation that moves fast with an emergent ontology may find itself governed by meaning that was never deliberately designed, only inherited from whatever the source systems happened to encode.

It is worth noting that this pattern appears across different approaches to automatic meaning generation. Removing the upfront modelling burden does not eliminate the bottleneck. It relocates it to a later stage, when the cost of correction is higher and the model is already load-bearing.

This connects to a harder question explored in The Authority Crisis in Data Governance: when meaning gets embedded in code, who has the authority to challenge it when it breaks something? Embedding decisions into automated rules makes them feel objective and inevitable. They are neither. Someone made that call, and in an emergent ontology, that someone is often the first workflow that happened to run.

Analytical Lens versus Operational Substrate

These risks are real but do not settle the argument in favour of meaning-first approaches. Waiting for consensus carries its own cost, paid silently in decisions made without data and in transformations that never quite launch. There is a second distinction worth naming.

Semantic layers built on top of data pipelines tend to serve analytical consumers: people querying for insight, building dashboards, asking questions of historical data. The ontology is a lens for looking at what happened. Foundry’s object model is operational. The objects are live and actionable inside workflows, not representations of reality for the purpose of analysis but participants in decisions as they are being made. A procurement object is not just a record of a transaction. It is an entity that can be acted upon, routed, enriched, and connected to adjacent objects in real time.

That operational continuity is the hardest thing to reconstruct by assembling components, because it requires the platform, the semantic layer, the governance model, and the workflow to be designed as a coherent whole rather than composed after the fact.

An ontology bolted onto a data pipeline can describe what happened. It cannot easily participate in what is happening. It is a mirror of the world rather than a lever within it: useful for reflection, but unable to move anything.

The Limits of Translation

This brings the argument to a point Nicolas Figay raised in the comments on Vlad’s article. Translation between representations is not a free operation. It requires that both sides are well-formed enough to correspond, that the mapping preserves what matters, and that it is actively maintained as models evolve. None of these are guaranteed by data contracts, however well designed.

The deeper problem is that organisations typically solve the surface version of this challenge while believing they have solved the real one. Agreed field names and shared schemas create the appearance of shared meaning without guaranteeing it. Two perfectly compatible data structures can mean entirely different things to the people who use them. That gap is where most federated governance programmes quietly collapse, long after the architecture review.

The structural answer Nicolas points toward is to stop trying to force a single unified representation and instead maintain multiple views simultaneously, with explicit mappings between them that preserve the differences rather than erasing them. Finance and logistics do not need to agree on what a customer is. They need to be able to translate between their definitions reliably, knowing what is preserved in that translation and what is lost. The mappings are not a workaround for incomplete agreement. They are the primary design work. And that reframes the goal: not unification, but the ability to move deliberately across different legitimate views of the same reality.

Principled distribution is not a discount on governance. It is a premium on engineering.

A Strategic Choice, Not a Technical One

The choice between meaning-first and data-first sequencing is not primarily a technical decision. It embeds assumptions about where understanding comes from in an organisation, who has the authority to define it, and what it costs to change it.

Meaning-first approaches locate authority in the modelling exercise, the governance team, and the enterprise architect. They are legible to executives and regulators who prefer clear lines of accountability. They are also slow, and they tend to produce semantic layers that domains consume rather than co-own. As explored in The CIO Should Eat the CDO, this is precisely the pattern that leaves governance roles accountable for outcomes they lack the structural authority to deliver.

Data-first approaches locate authority closer to operational reality. They are faster to deliver value and more likely to reflect how the organisation actually works rather than how it was designed to work. They are harder to govern and audit, and the meaning they produce can be difficult to change once it is embedded in live systems.

A third failure mode sits between the two. When federated governance retains the governance but loses the distribution, it is not federated at all. It is centralisation with better vocabulary, reproducing the same bottlenecks at a different level.

Neither approach is simply better. They are different theories of how organisations come to share understanding, and each carries costs that the other does not. The question worth asking before choosing is not which approach is more architecturally elegant. It is which failure mode your organisation is better equipped to recover from: the slow death of meaning-first consensus that never quite arrives, or the fast lock-in of emergent meaning that was never quite right.

That is a strategic question. It belongs at the level where data strategy and organisational design meet, which is also where most data conversations do not yet reach.

A note after publication

After this essay was published, Nicolas Figay added a clarification worth preserving. The sequencing dilemma I describe still assumes that stable, shared meaning is the goal, even if hard to reach. His point is sharper: permanent agreement on meaning is not a destination we have failed to reach. It does not exist. Meaning is always local, always temporary, always contextual. Different parts of the organisation will always understand the same concept differently, and that is not a problem to fix. It is the condition to design for. The practical question that raises is how organisations make good enough decisions when meaning is never fully settled, and that is the work.

Further Reading

The ideas in this essay are built upon several foundational works and ongoing conversations. Vlad Radziuk’s year-long reconstruction of the Palantir approach surfaces the right questions about ontologies, and the human dimension of decentralisation, and is the direct origin of this essay. The companion piece The Data Platform Was Never a Place develops the argument that a platform is a logical construction of shared contracts and semantics rather than a physical location.

The tension between automated governance and human judgment is examined in The Authority Crisis in Data Governance, and the structural consequences of governance roles without authority are explored in The CIO Should Eat the CDO. The sequencing argument connects further to The Logic Has to Stand on Something, The Metadata Coordination Problem, and When Everything Becomes Findable, all available at bbroum.substack.com.

For the foundational frameworks, the FAIR Data Principles at go-fair.org provide a useful starting point for thinking about what well-formed, interoperable data actually requires. The concept of bounded contexts from Domain Driven Design, developed by Eric Evans in his foundational book of the same name, provides the intellectual foundation for why different domains should maintain locally coherent definitions rather than being forced into a single shared model. Conway’s Law, Melvin Conway’s 1968 observation that organisations design systems mirroring their communication structures, remains essential reading. The Inverse Conway Maneuver, designing the organisation to produce the architecture you want, was developed by Martin Fowler and Thoughtworks and is further elaborated in Team Topologies by Matthew Skelton and Manuel Pais.

This essay is part of an ongoing conversation about governance, organisational learning, and what it actually takes to make both work in organisations that keep changing.

Subscribe now

Two Readings of the Tower

The air traffic control metaphor keeps appearing in governance conversations for good reason: nobody wants planes colliding because the tower and the cockpit were not coordinating. But there are two fundamentally different ways to read that metaphor, and they lead to governance designs that are not merely different in degree. They are different in kind.

The first reading is about authority. The tower holds absolute protocol control over the airspace. If the tower says hold, the pilot does not take off. The separation between cockpit and tower is not a preference. It is a safety requirement, because a pilot who also ran the tower would naturally prioritise their own flight schedule over the safety of everyone else in the airspace. Governance, in this reading, is the power to stop.

The second reading is about flow. The tower’s job is not primarily to ground planes. It is to keep traffic moving safely, to use accelerator and brake, to sequence departures and arrivals so that the maximum number of flights reach their destinations without incident. The tower updates its protocols when new aircraft types enter service, when traffic volumes shift, when a near-miss reveals a gap in the existing rules. It learns from what actually happens in the airspace, not just from what was anticipated when the protocols were written. Governance, in this reading, is the capacity to adapt.

These are not the same model with different names. The first produces a static enforcement layer. The second produces a continuous learning system, one that keeps traffic moving, distributes accountability to the teams doing the work, and builds the organisational capacity to govern itself rather than waiting for clearance from above.

The Hidden Cost of Enforcement

In most organisations I have seen, governance thinking has been built on the first model even when it claims otherwise. The appeal is understandable: enforcement gives clarity, a gate that passes or fails is easier to audit than a learning loop that updates continuously, and authority centralised in a governance function is easier to name than accountability distributed across teams. But the hidden cost surfaces under pressure. Governance logic designed at a point in time is right at the moment of design and increasingly wrong as the world it was written for continues to change. The gap grows invisibly until it produces a failure that cannot be explained by the system that certified everything as compliant.

This is not a failure of enforcement. It is a structural limitation of any governance model that treats its own logic as settled. Data quality is not physics. It is contextual. What counts as important shifts as the business shifts, and the boundary condition that was right when it was written is not automatically right when the context has changed. The organisation that treats this as a maintenance problem is always behind.

Consider what happens in a large organisation that invested heavily in a data governance programme. The quality gates were built, the contracts were defined, and the dashboards showed green. Eighteen months later a product team quietly stopped using the certified data pipeline and built their own. When asked why, the answer was simple: the governance logic had been written for last year’s product structure, and nobody had the authority or the mechanism to update it.

The gates were passing data that no longer meant what the governance team thought it meant.

The programme had not failed. It had frozen.

Three Principles of Adaptive Governance

What governance actually demands, in any domain where complexity and change are constants, is a model built on three principles that reinforce each other.

The first is just-in-time, just-enough governance (JIT-JE). Not a comprehensive ruleset defined upfront for every possible scenario, and not a lightweight framework that avoids the hard questions. A governance design deliberately scoped to what is load-bearing now, with an explicit mechanism for updating that scope as conditions change. The discipline it encodes is the same regardless of domain: govern only what needs it, when it needs it, at the layer where it actually matters. Everything else is overhead that slows flow without improving safety.

The second is distributed accountability. Teams empowered to act within boundaries they understand and helped shape carry accountability differently from teams that wait for clearance from above. They notice when the boundaries are wrong. They surface the signals that the governance logic has not yet absorbed. They are closer to operational reality than any central function can be, which means they are also closer to the failure modes that matter.

Most governance structures are built alongside the operation rather than inside it. That distance is not just an inconvenience. It is a structural disconnection from the operational experience that is the primary source of learning, which is precisely why distributed accountability is not a philosophical preference but a structural necessity. This is what absorptive capacity looks like in practice: the organisational ability to recognise weak signals at the edge, bring them inward, and metabolise them into updated governance logic before the gap between rules and reality turns into real operational cost. A governance model that stops teams from acting without approval also stops them from learning. One that enables flow while building in structured reflection builds the organisational capacity to govern itself.

The third is structured adaptation. Empowerment without reflection is not governance. It is autonomy without accountability. The mechanism that connects the two is Stop! Think! - the structured point in the operating rhythm where teams examine not individual decisions but the patterns those decisions have produced, surface what the governance logic failed to anticipate, and update the boundary conditions before the next cycle begins. This is not a compliance review. It is an organisational learning exercise, and it is where governance earns its keep.

From Tower to Learning System

These three principles together describe a system that learns. It sets boundaries based on current understanding, releases autonomy within those boundaries, observes what actually happens, and adjusts. Not once. Continuously.

The tower worth building is not the one with the authority to stop. It is the one with the discipline to keep learning.

Frameworks and Further Reading :

The three principles in this essay reflect a broader operating framework called Tight-Loose-Tight, or TLT (pioneered by my good friend Rune Ulvnes at CoWork AS). The first Tight phase sets boundaries and direction. The Loose phase releases autonomy within those boundaries. The second Tight phase, the Stop! Think! moment, is where structured reflection updates the boundary conditions before the next cycle begins. The rhythm applies across governance, leadership, and organisational learning. It is developed in full in the governance paradox essay in this series.

The opposite pattern tends to emerge without design, direction, or purpose: organisations tighten after a failure with disciplined execution, then drift back to looseness without ever asking what the failure revealed or what they were governing for in the first place. Call it Loose-Tight-Loose, or LTL. The execution is real. The intent was never there.

This essay describes a governance challenge that predates agentic AI but becomes operationally critical because of it. When autonomous systems act on governance logic faster than any review cycle can catch, the gap between static rules and shifting reality is no longer a management inconvenience. It is an operational failure mode. The adaptive flow model is not a response to agentic AI. It is the precondition for governing it.

JIT-JE is not specific to data governance. The same discipline applies wherever complexity and change make comprehensive upfront rule-setting impractical: enterprise architecture, organisational design, product governance, and beyond. The final letter is context-dependent. The underlying principle, govern only what needs it, when it needs it, at the layer where it actually matters, is the same regardless of domain.

The two governance models in this essay map naturally onto the Cynefin framework. Enforcement-based governance works well in complicated domains, where cause and effect are knowable, rules are stable, and expert analysis produces discoverable solutions. Adaptive flow governance is necessary in complex domains, where cause and effect only become clear in retrospect, rules must evolve as the system is observed, and learning is the primary mechanism of control. The Cynefin framework and its implications for methodology and diagnostic thinking are explored further in the Mythology of Methodology series.

The debate about who should own data governance has produced a generation of sophisticated arguments. The CIO should absorb the CDO because system authority must follow the source. The CDO should be split into a Chief Analytics Officer because one role cannot carry both operational governance and analytical depth. The Constitutional Architect should define global standards that computational governance then enforces. The instinct toward ownership is not irrational. When governance fails, organisations need someone accountable, and ownership is how accountability gets assigned. The problem is not the instinct. It is that ownership without the right sequence produces accountability for outcomes nobody had the structural conditions to deliver. And that debate has, for the most part, been asking the right question second.

The question organisations keep arguing about is ownership. The question that actually determines whether governance works is sequence.

By the end of the exchange that prompted this essay, both sides had converged on the same diagnosis: the status quo CDO is broken, and whoever owns the logic needs real authority over what the logic says and real accountability when it produces the wrong outcome.

That convergence is significant. It means the debate was never fundamentally about org charts. It was circling something deeper, and that something is what this essay attempts to name.

Subscribe now

A Debate With a Hidden Assumption

The original essay arguing that the CIO should absorb the CDO drew a sharp and well-constructed response. The counterargument ran as follows: policy-as-code and computational governance solve the authority problem by moving the CDO’s influence from advocacy to architecture. Hard gates in the deployment pipeline are not recommendations. They are enforced. The CDO defines what goes into the gate. The CIO builds the engine that runs it. Neither absorbs the other. Both are necessary.

It is an elegant resolution, and largely right about the mechanism. Computational governance embedded in deployment pipelines is genuinely better than policy documents nobody reads and review boards that create bottlenecks without creating accountability. The authority crisis essay named this problem precisely: governance without system authority is expensive advocacy, and advocacy does not scale.

But the policy-as-code argument contains a hidden assumption: it presupposes that the inputs feeding those gates are already trustworthy enough to govern. If the source systems producing data were never designed with data quality as a first-order requirement, then a hard gate at the deployment layer is not governing reliable data. It is enforcing standards on contested, inconsistently defined inputs and calling the result governed. The authority crisis essay described what follows as authority laundering: developers implement logic from product owners who defer to architects who reference policies from governance teams uninvolved in actual decisions.

The gate passes. The business outcome fails. And because the gate passed, nobody knows why.

And even when the gate is working as designed, it may be enforcing the wrong definition, a kind of meaning laundering where contested business judgment is automated rather than resolved, because the one that was easiest to code displaced the one that was true to the business.

Distributing the implementation does not distribute the accountability. It dissolves it.

Source governance means something more specific than data quality policies. It means governing the upstream applications, the ERPs, the CRMs, the operational systems, and the engineers who build them, so that data quality is treated as a feature of the application rather than after-the-fact exhaust. The coordination layer built above ungoverned source systems can be architecturally sound and operationally misleading at the same time. It becomes a faithful map of an ungoverned territory: coherent in its own logic, accurate in what it describes, and wrong about what the business needs it to mean.

What the Logic Has to Stand On

Think of governance architecture the way you might think of a building. The sophistication of the upper floors depends entirely on whether the foundation is holding. You can design the most elegant decision layer in the industry, embed semantics, enforce contracts, automate quality checks at the point of consumption. If the operational systems feeding that layer are producing inconsistent, ungoverned inputs, the sophistication above does not just compound the problem. It obscures it.

Curation and enforcement give the impression of trustworthiness the underlying data has not earned. The more elegant the governance architecture above the source, the more confident the decisions built on it, and the harder the failure is to locate when it arrives. You are making faster, more automated decisions on data nobody fully trusts.

In an agentic environment this is not a theoretical concern. Agents do not read faulty reports and apply judgment to correct them. They act. A pricing agent operating on stale product classifications does not flag the inconsistency for human review. It mis-prices, at scale, before anyone notices. An inventory agent following an identifier, the reference code a system uses to recognise a specific product or asset, that has drifted between systems does not pause to reconcile the discrepancy. It produces what might be called a silent breakage: the system does not fail because the data is visibly wrong, but because the map changed without notification. Humans inherit the cleanup, and because no gate fired, the failure is structurally invisible at the point where it occurred.

Agents also write back. Every action generates new operational data into the same ungoverned sources that fed the decision. The feedback loop between agent and source is tighter and faster than anything the traditional governance debate was designed to manage.

Ungoverned source systems do not just produce unreliable inputs. In an agentic environment, they receive unreliable outputs that compound the original problem.

Sequence, Not Ownership

These are real questions and the answers matter. But they are second-order questions. The first-order question is whether the foundation that governance logic has to operate on is itself reliable.

Source governance and computational governance are not competing architectures. They are sequential layers. The first makes the inputs trustworthy. The second makes the logic enforceable. The third, the decision and value layer, is where business meaning is extracted and economic outcomes are driven. Each layer depends on the one beneath it. Skipping the sequence does not accelerate the journey. It guarantees that the layers above will fail in ways that are difficult to diagnose, because the failure is invisible at the point where it occurs. In practice, organisations will advance source and computational governance in parallel. That is not the problem. The dependency runs in one direction: the gate cannot create the trust the source failed to earn.

v

An organisation invests in computational governance, embeds data contracts, deploys hard gates in its deployment pipeline. The gates pass. Deployments succeed. Six months later, agent-driven decisions are producing outcomes that do not match business expectations. The investigation reveals that the source systems feeding the governance layer were never consistently governed to begin with. Two operational systems used different identifier formats for the same product. The gate enforced a contract on top of that inconsistency and certified it as compliant.

The sophistication of the layer above made the problem harder to find, not easier, because the gate’s passing created confidence the foundation had not earned.

When the sequence was corrected, the fix was not architectural. It was a decision by the CIO’s team to treat product identifier consistency as a release requirement for the source systems themselves, the same standard applied to uptime and security. The gate did not change. What changed was what the gate was allowed to stand on.

The authority crisis therefore splits cleanly: one authority over what the logic should say, another over whether the systems can be made to make it true. These are not the same authority and they do not resolve together. Coordination authority belongs to whoever can enforce standards across domains. Source governance authority belongs to whoever controls the operational systems themselves. Conflating them is how organisations end up funding coordination infrastructure built on foundations nobody governs. In the federated metadata series this showed up as the Foundational Tax: the price an organisation pays when it builds coordination and governance layers on top of source systems that were never governed to be trustworthy in the first place.

Solving the first without addressing the second produces sophisticated governance of unreliable foundations.

What This Demands of the Organisation

What Patrick called the Constitutional Architect and what the original essay proposed as the Chief Analytics Officer are closer to each other than the debate suggested. Both name the same unfilled position: whoever owns the logic governing what data means must have real authority over what that logic says and real accountability when it produces the wrong outcome. The CIO takes source authority over the operational spine. What remains, the navigation role the CDO was always meant to fulfil but rarely had the mechanism to deliver, is not diminished by this. It is finally unburdened from trying to fix pipes it never owned, and free to do the work it was always supposed to do: govern what data means and where it creates value. The old CDO mandate does not survive the sequence intact. It continues in two more honest forms. The title may remain. The conflation cannot.

There is a fair objection here. If the CDO is broken by lack of authority, the CIO is at risk of being broken by tradition. The same leader who owns source systems has historically optimised for stability and continuity, not for data quality as a first-order outcome. Agentic AI changes that calculus, not because CIOs will suddenly want to, but because the cost of neglect is no longer a bad report. It is a system that stops working. The sequencing argument does not assume a reformed CIO. It assumes an environment where the consequences of ungoverned source systems finally land where the authority to fix them already resides.

What the CIO is now explicitly on the hook for is not data strategy in the traditional sense. It is the operational reliability of the data that agents will act on, treated with the same engineering discipline as system availability. What the navigation role keeps is everything that requires judgment about meaning: which agents drive real business value, and where the untapped signal lives. These are not diminished responsibilities. They are the responsibilities the role was always supposed to carry, now without the weight of a plumbing problem that was never theirs to solve.

Locating data governance with whoever owns the source systems is not an organisational preference. It is a structural precondition.

The sequence is not optional. It is structural.

What Comes Next

The next frontier is not who owns the logic. It is building the foundation that makes the logic trustworthy at the speed agents will demand. That work is unglamorous, slow, and invisible in delivery metrics. It does not generate the architectural excitement of a federated mesh or the operational elegance of policy-as-code. The measure of it is not a progress metric but the absence of cascading failure. You do not celebrate a milestone when source governance matures. You notice, quietly, that the investigation that used to take six months now takes six hours, that agents produce outcomes the business recognises rather than anomalies nobody can explain. Progress here is measured in problems that do not escalate, not in features that ship.

It is, however, the work that determines whether the governance sophistication built above it is real or performed.

The test is simple. Can you name the person with authority to change a source system validation rule when it breaks your highest-value agent? Not the governance team. Not the data quality council. An actual name. If you cannot, the sequence is broken before it begins.

A note on where the thinking stands: this essay argues for sequencing with more confidence than I currently have in all of its implications. The argument is directionally right, but source governance at the speed agents will demand is itself an unsolved problem. And to name the most likely misreading directly: this is not an argument against computational governance. It is an argument against asking computational governance to compensate for foundations it cannot control.

The harder version of the foundation test is not just naming one person, but resolving what happens when the quality requirements belong to the consumer’s context and the source owner has no obligation to meet them. In federated and multi-entity organisations that question does not have a clean answer.

A related open question is granularity. Source governance applied uniformly across all data in a system is neither practical nor necessary. The harder discipline is identifying which data elements are genuinely critical, the ones whose quality failures cascade into risk models, pricing decisions, financial reconciliation, or customer outcomes, and governing those with the rigour the sequencing argument demands. Without that identification, source governance becomes as unfocused as the ownership debates it is trying to replace.

Whether organisations have the courage to make that separation honest, in structure and not just in name, is the real question the sequencing argument leaves on the table.

The question that stays with me is simpler than any framework: are you funding the foundational work as intentionally as you fund the systems that depend on it? Not a governance programme. Not a role. The actual investment in time, authority and attention required to make source systems trustworthy before the logic above them is asked to perform. Most organisations have not answered that question honestly. The debate about who owns the logic tends to start before anyone has asked whether the ground it stands on was ever prepared.

If you are working through this in your own organisation, I would genuinely like to hear what you are finding. What is proving harder than expected? What is carrying forward from earlier governance attempts? The thinking here will keep developing, and the most useful input rarely comes from the literature.

Modular catalogs recognize this: the Platform Catalog for builders, the Governance Registry for compliance, the Data Marketplace for consumers. Purpose-built, fit-for-context, deliberately bounded. When everything becomes findable in one catalog, nothing gets found. Separate catalogs solve that.

But when metadata about the same object lives in multiple places, how does it stay coherent? This is the coordination challenge — and it’s architectural, but also about authority:

Who maintains coherence across distributed systems, and who holds the power to enforce the standards that make coordination possible?

And as agentic AI moves into operational workflows, the stakes shift from inconvenience to operational failure. Humans can mentally stitch together inconsistent metadata. Agents cannot. When an agent follows an identifier that has drifted between systems, the failure is immediate and operational — not a report to fix later, but a system that stops working now.

Subscribe now

The Essays

When Everything Becomes Findable, Nothing Gets Found makes the case for modular catalogs and shows why comprehensive approaches collapse. The Platform Catalog for builders operates at speed. The Governance Registry for compliance prioritizes coverage and auditability. The Data Marketplace for consumers curates ready-to-use products. Different rhythms, different quality bars, deliberate boundaries.

The Metadata Coordination Problem examines how metadata stays coherent across distributed systems without recreating centralization. Federated metadata treats coordination as fundamentally distinct from cataloging — using shared identifiers and synchronization standards at the boundaries where domains genuinely overlap. But coordination requires authority, not just good intentions. The question is where that authority lives.

What Federation Actually Costs identifies three inherent costs of distributed ownership that become blockers when unrecognized: expertise in metadata coordination, mechanisms for version alignment across domains, and authority to enforce coherence standards. These aren't temporary friction or implementation bugs — they're ongoing investments that successful federation requires by design.

Why This Matters Now

Federation isn’t a future possibility — it’s the architecture that emerges when intelligence operates at the edges. When agents live in workflows at the point where data originates, you cannot centralize what lives distributed.

The question isn’t whether to federate. It’s whether organizations fund what federated metadata actually demands — or treat coordination as something that should just happen, then watch initiatives stall on metadata problems nobody budgeted for.

A Learning Journey

These essays represent my own exploration of what federation actually demands. The first essay was straightforward — cataloging’s failure modes are well-traveled ground. The coordination problem in the second essay pushed me into less settled territory, working through how federated metadata stays coherent without recreating centralization.

The third essay is where I’m still learning. The coordination tax feels real and observable, but I’m not yet confident I have the mental models right. The relationship between distributed ownership and central discipline, the way agents change the calculus, the question of what “minimum viable coordination” actually means in practice — these need further iteration and more mature thinking.

I’m publishing this as exploration, not conclusion. If you’re navigating similar challenges, I’d genuinely value hearing what rings true, what doesn’t, and where the thinking needs refinement. Which question hits your current challenge?

Additional Reading

For more on the authority question that runs through these essays:

• The Authority Crisis in Data Governance — why governance without enforcement authority becomes expensive advocacy

• The CIO Should Eat the CDO — why system integrity has replaced data governance as the organizing principle

The argument for federation remains compelling: comprehensive catalogs collapse under their own weight, and domains genuinely should own what they know best. But as agentic AI moves into operational workflows — living where data originates rather than consuming it downstream — federation shifts from architectural preference to operational necessity. The question is no longer whether to federate, but how to do it well. And that means understanding what it actually demands.

This third essay in is where I’m still learning. The coordination tax feels real and observable, but I’m not yet confident I have the mental models right. The relationship between distributed ownership and central discipline, the way agents change the calculus, the question of what “minimum viable coordination” actually means in practice — these need further iteration and more mature thinking. So I’m publishing this as exploration, not conclusion.

Subscribe now

The Reality We're All Learning

Consider what happens when engineering restructures how they catalog infrastructure specifications — consolidating fields, changing identifier formats, improving their internal workflow. Entirely reasonable within their domain, and exactly the kind of local optimization that federation is meant to enable.

But compliance’s quarterly regulatory report now shows null values in critical fields. Data analytics built on the previous field names stop producing results. Maintenance work orders can no longer be assigned because the identifiers changed format. Engineering optimized their catalog. Three other systems broke.

In a centralized model, one team owns schema changes and coordinates migrations across all systems — at least the responsibility is visible, even when execution is slow. In federation, the coordination cost distributes across domains. Which often means it doesn’t happen at all until dashboards fail, reports go blank, or work orders stop resolving.

We traded one large, visible coordination problem for many smaller ones distributed across teams. These are what we might call silent breakages — systems failing not because data is wrong, but because the map changed without notification. In automated pipelines, agents don’t pause to question whether an identifier still means what it meant yesterday. They follow it, fail operationally, and humans inherit the cleanup.

Three Taxes Worth Understanding

As organizations navigate federated metadata, three costs keep surfacing. They’re not failures of the approach — they’re taxes inherent to distributed ownership. The question is whether organizations recognize and fund them, or let them accumulate as hidden drag until they become blockers.

The Expertise Tax. Domain teams excel at their domains, not at metadata management. When engineering restructures their catalog, they’re thinking about better workflows — not downstream dependencies in compliance or analytics. This is a version of the broader authority question: we pushed judgment into domains without ensuring they had either the mandate or the capability to exercise it across boundaries. The tax is real: invest in developing metadata literacy within domains, or fund explicit coordination mechanisms. Pretending the choice doesn’t exist is where organizations stumble.

The Versioning Tax. One catalog means one version to manage. Federated catalogs mean each domain versions independently — and they do so on different timelines for legitimate reasons. Engineering moves to version 3.0. Compliance stays on 2.1 because regulatory mappings take months to validate. Data migrated to 2.5 with custom extensions. Now the bridges between domains must handle three versions simultaneously, with backward compatibility across every combination — so one engineering change becomes as many coordination challenges as there are downstream dependencies. The cost here isn’t just technical; it’s the ongoing human negotiation required to keep those bridges passable. This tax requires investment: either you build translation layers that handle version multiplicity, or you establish governance mechanisms that coordinate version migrations. The tax doesn’t disappear — the question is how you pay it.

The Standards Tax is perhaps the most instructive.

Federation requires more central discipline, not less — it simply requires less central execution.

Someone must create the standards that enable coordination — shared identifiers, synchronization protocols, metadata schemas where domains overlap. You can distribute the work. You cannot distribute the logic of what makes the work coherent. So organizations create coordination functions — sometimes called “federated governance teams” — and the challenge is that these functions often lack the formal authority to enforce the standards they set. They recommend rather than require, which is precisely the condition under which bridges start to drift. This connects to the authority question raised in “The CIO Should Eat the CDO” — which argues that system integrity, not just data quality, is the real issue, and that requires architectural authority, not policy influence. Even selective coordination requires someone with cross-domain authority. The tax here is explicit: fund the coordination function with real authority, or pay the cost in drifting standards and silent breakages.

But what actually grants that authority in a distributed organization? How do you establish it when it doesn’t exist? What mechanisms enforce standards when domains resist? These questions don’t have universal answers — they depend on organizational context, existing power structures, and how system accountability is already distributed. What’s clear is that treating them as implementation details rather than design constraints is where federation attempts tend to stall.

These three taxes aren’t temporary friction — they’re ongoing costs of distributed ownership. Organizations that recognize them as legitimate line items and fund them deliberately tend to navigate federation successfully. Organizations that treat them as problems that better architecture should eliminate tend to struggle.

What Earlier Federations Taught Us

These taxes aren’t unique to metadata. Data mesh — as one concrete form of federated ownership — surfaced similar challenges. Domain teams building data products discovered they needed metadata expertise they didn’t have (the Expertise Tax), product interfaces drifted across domains despite good intentions (the Versioning Tax), and someone still needed to define what “data product” meant consistently across the organization (the Standards Tax).

The implementations that worked treated these not as implementation bugs but as inherent characteristics of federated models requiring explicit design: invest in domain capability development, establish interface standards with real enforcement mechanisms, and fund coordination as a first-class function rather than an afterthought.

The lesson carries forward: you can decentralize the work, but you cannot decentralize the standards that make the work coherent across boundaries. Successful federation requires being honest about where central discipline must live, even as execution distributes.

What Makes Federation Navigable

If these taxes are real but federation is increasingly necessary, what makes it work?

The answer is that the bridges themselves need to be fewer and more deliberate than we instinctively build them. Disciplined selectivity — linking only where coherence genuinely changes decisions — keeps the bridges manageable. These are the bridges built on shared identifiers, the mechanism explored in “The Metadata Coordination Problem”: without stable identifiers that systems agree on, there is no bridge to maintain, only parallel descriptions that happen to share a name. Return to the engineering restructuring scenario: compliance audit trails needed real-time coherence. Operational maintenance systems, yes. Consumer analytics dashboards, probably not. Most organizations reverse this default, treating everything as requiring coordination and only later discovering they cannot afford it.

The second answer is organizational: treating coordination as an explicit, funded capability rather than something that happens in the gaps between domain responsibilities. Not a centralized team that owns everything, but a coordination function — the CIO function, as argued in “The CIO Should Eat the CDO” — with clear authority over standards and clear boundaries around what it does not control.

Why This Matters More Now

Agentic AI changes the calculus. Agents don’t sit in dashboards waiting for human interpretation — they live in operational workflows, making decisions at the point where data originates. An agent managing maintenance schedules operates where work orders are created. An agent optimizing supply chains operates where inventory moves. An agent supporting compliance operates where inspections are recorded.

This makes decentralization less of an architectural choice and more of an operational reality. You cannot centralize what lives distributed across workflows. But agents also make the coordination constraints more acute — because they traverse systems at speed, and they cannot mentally stitch together inconsistencies the way humans do.

Federation isn’t a future possibility to evaluate. It’s the architecture that emerges when intelligence operates at the edges rather than the center. The question is whether organizations recognize the patterns that make it work and fund them honestly — or treat coordination as something that should just happen, then watch their agent initiatives stall on metadata problems nobody thought to budget for.

What I’m Still Learning

I’ve argued for federated metadata as the path beyond comprehensive catalogs, and I still think that’s right — not as preference, but as the architecture that fits how organizations actually operate and where agentic AI actually lives. But navigating it well requires recognizing what it demands.

Federation doesn’t eliminate coordination cost; it redistributes it.

What is the minimum viable coordination for your context? And are you funding it as intentionally as you fund the systems it connects?

The organizations that will navigate this well aren’t the ones with the most sophisticated architecture. They’re the ones that treat coordination as a design constraint from the start, fund the capabilities it requires, and resist the comfortable fiction that better ownership models make the hard work disappear.

What patterns are you discovering as you navigate federated approaches? If you’ve lived through data mesh or similar shifts, what carried forward? I’m genuinely curious what’s working — and what’s proving harder than expected.

Subscribe now

The Coordination Problem

Consider a bridge: specifications in engineering tools, inspections in compliance systems, risk metrics in data catalogs. Three specialized repositories, three legitimate perspectives on the same physical asset. This separation makes operational sense — but when raw engineering data becomes processed safety metrics and then curated analytics products, it crosses all three domains.

We need bridges between specialized maps, not another mega-map.

Federated Coordination

There is an emerging architectural approach to this challenge — one that treats coordination as fundamentally distinct from cataloging. Rather than merging systems or forcing convergence, it establishes shared identifiers and synchronization standards at the boundaries where domains genuinely overlap. This is variously called federated metadata or a metadata mesh, and it represents a meaningful shift in how organizations think about metadata coherence.

When the same asset appears across multiple systems, those systems reference a shared identifier — the precise point at which coordination becomes possible — and synchronize only the overlapping fields.

Without a stable shared identifier for that physical bridge, the engineering record, the inspection history, and the risk analytics are describing three different things that happen to share a name.

This can be understood as a third wave of decentralization in enterprise architecture. After microservices decomposed operational systems, and data mesh — as one form of federated ownership — decentralized analytical platforms, federated metadata addresses the layer beneath both: how do we coordinate the descriptions of things without consolidating ownership of those things? One named instantiation of this thinking is the Meta Grid, a pattern coined by practitioner Ole Olesen-Bagneux, which gives specific architectural shape to these ideas. Crucially, the Meta Grid is not a product to be purchased but a discipline to be enforced — a standard for how systems reference shared entities and synchronize at their boundaries. Whether that particular pattern endures or evolves, the underlying approach addresses something real.

Why Agents Need This

Humans can jump between systems and mentally stitch them together. Agents cannot.

Agents automating workflows must traverse a chain: infrastructure → sensors → data → policies → analytics → actions, and back again. If the metadata fragments along that chain are not linked, the agent gets partial views and cannot move end-to-end. An agent might apply the wrong maintenance rule to the right bridge precisely because the identifier it is following has drifted between systems — and it has no way of knowing.

This is not a data quality problem in the traditional sense. The data in each domain may be perfectly accurate within its own context. The problem is that the maps don’t agree on what they are describing. For agents operating at the speed of automated decisions, that disagreement is not a nuisance to be resolved later. It is an operational failure in the present.

This is where federated metadata diverges from earlier decentralization philosophies. Decentralizing ownership is right — but it assumes coordination without defining how. Ownership without coordination produces islands. Coordination without federated ownership produces the monolith we were trying to escape.

Agents surface these failures faster and at greater scale than humans do — but it is still humans who absorb the consequences. The analyst chasing the wrong revenue table, the compliance officer reconciling inspection records that no longer map cleanly, the engineer explaining why a maintenance system acted on stale data. Automated systems compress the time between a coordination failure and its operational impact. They do not change who has to clean it up.

The Authority Question

If metadata coordination spans engineering systems, data catalogs, security tools, and operational platforms, who ensures coherence?

Federated approaches require explicit domain ownership — engineering, data, and security each own their systems. But someone must coordinate across domains, and that role requires architectural authority, not just policy influence. A governance function that can recommend standards but cannot enforce them across systems will always lose to the operational priorities of the teams it is trying to align — this is the same authority problem that undermines the CDO role, now surfacing at the coordination layer. What is at stake is system integrity: when metadata fragments fail to align, the operational systems that depend on them become unreliable. The question of who holds that authority, and how they exercise it without recreating centralized bottlenecks, is explored in“The CIO Should Eat the CDO” — but the premise here is straightforward: coordination without authority is advocacy, and advocacy does not scale.

Discipline Over Sprawl

Lightweight connectors sound appealing — until they multiply into their own mess. Organizations building federated coordination often see it proliferate: standards multiply, versioning gets complex, and the temptation grows toward a grand unifier that risks failing like the old catalog it replaced.

Most metadata stays domain-local, and coordination overlaps are smaller than we tend to assume. Engineering specifications rarely need linking to consumer analytics; security frameworks do not need real-time synchronization with operational dashboards. Federated coordination demands disciplined selectivity — linking where coherence genuinely changes decisions, and resisting the gravitational pull to expand scope once the infrastructure exists. That discipline is as much organisational habit as architectural choice.

The real work isn’t building a better catalog; it’s choosing which bridges between catalogs are worth building at all — and being honest about what it will take to keep them standing.

How are you navigating metadata across specialized systems? Have you built coordination that scaled, or watched it sprawl? I'm curious to hear your experiments.

The more we expand what counts as “data,” the more we might be building cathedrals when we need workshops.

The landscape has shifted. Data no longer means rows and columns. It means chat streams and video footage. It means LiDAR scans for highway sightlines or bridge clearances, and documents specifying electrical installations sealed behind tunnel ceilings. Drone imagery feeds algorithms that monitor bridge integrity. Each carries meaning, generates insight, demands governance.

Yet the traditional response—catalog it all—may be solving yesterday’s problem with tomorrow’s scale.

The Weight of Comprehensiveness

An enterprise data catalog promises one authoritative registry of all metadata across every data type. One interface. One source of truth. Complete lineage.

But operational reality tells a different story: the catalog becomes heavy. Maintaining metadata for structured tables is one challenge; maintaining it for video streams, chat logs, and infrastructure documents is another entirely. Who defines what metadata matters for a video clip? How do you catalog a LiDAR scan that only becomes meaningful when calculating dangerous cross-fall in a specific curve? How do you keep metadata fresh for data that exists only momentarily?

Modern AI-driven auto-tagging can be useful for pattern recognition, but proves insufficient alone—it often increases dilution by creating thousands of tags without business context and eroding user trust.

The economics become strained: cost to catalog must be weighed against asset value, and not every element justifies the investment.

The catalog becomes slow—not just in performance, but in adapting to new data types and reflecting how people actually work.

The catalog becomes diluted. When everything carries equal weight, finding the genuinely critical becomes harder. Users work around the catalog rather than with it.

In trying to make everything findable, we’ve created a landscape where what matters most gets buried.

Different Contexts, Different Needs

We’re conflating distinct contexts under one umbrella. A data engineer building pipelines has different needs than a governance officer maintaining Records of Processing Activities. A data scientist exploring features has different needs than a business analyst consuming pre-built reports or an ML engineer looking for AI-ready datasets.

Consider three fundamentally different functions:

• The Platform Catalog is for builders, optimized for speed and operational metadata. It answers “What’s the schema?” and “How fresh is this?” Its value comes from being lightweight, fast, and tightly integrated with transformation tools.

• The Governance Registry is for risk and compliance, optimized for coverage and traceability. It tracks what data exists, where it came from, who owns it, how it’s processed. It connects to data valuation systems and feeds regulatory requirements. Its value comes from comprehensiveness and auditability.

• The Data Marketplace is for consumers, optimized for consumption-ready products. It showcases finished data products and data marts—analytics-ready datasets, AI-ready features, pre-built aggregations. Its value comes from preparing and packaging solutions for immediate use, not cataloging raw assets requiring interpretation.

These operate in different rhythms with different quality bars. Forcing them into one system creates coherence on diagrams while creating friction in practice.

The Modular Alternative

In practice, this means the Platform Catalog focuses on what’s actively in use—structured tables, streaming chat data, processed drone imagery being fed into bridge monitoring algorithms. Raw LiDAR scans waiting for a specific engineering calculation—massive in volume, uncertain in utility until a project needs them? Not its concern.

The Governance Registry focuses on compliance and risk. It tracks personal data regardless of location—customer records in databases, faces in video footage, voices in chat transcripts. It knows that electrical installation documents exist sealed behind tunnel concrete, creating liability even when physically inaccessible. But it doesn’t try to be a search engine for every table schema.

The Data Marketplace curates consumption-ready products. A processed dataset analyzing bridge structural trends from drone imagery—packaged as analytics-ready tables with clear business definitions—might appear here. LiDAR-derived datasets showing clearance heights and sightline calculations for highway planning, prepared as ready-to-use metrics, certainly would. An AI-ready feature set built from anonymized chat transcripts for sentiment analysis might qualify. Raw infrastructure documents, unprocessed scans, and tables requiring deep technical knowledge never appear.

This modularity costs you the single pane of glass, but gains fit-for-purpose tools. The key is ensuring these modules share intelligence through standards like OpenLineage or DCAT—turning what might seem like fragmentation into deliberate distributed architecture. That allows coordination without centralization, where each catalog stays fit for purpose while contributing to organizational coherence.

Modularity also forces honest questions: what doesn’t get cataloged? Not everything needs to be findable through a central catalog;

some data is perfectly discoverable in the operational systems where it lives.

And critically, we must decouple visibility from control. A nuclear reactor is heavily governed, but it’s not discoverable on a public library shelf. Similarly, documents detailing electrical installations behind tunnel concrete require rigorous version control and access policies at the source, regardless of whether they ever appear in a searchable directory.

Cataloging has costs. Those costs are worth paying for data meeting specific criteria: regulatory risk, reusability across teams, business criticality, or high frequency of access. But “data that matters” is smaller than “all data that exists.”

The Strategic Choice

The choice should be intentional. If your organization is governed by regulatory compliance in structured industries, the comprehensive Governance Registry might justify its weight. If your organization runs on a modern data platform where engineers build and transform, the Platform Catalog might suffice. If you’re democratizing data access across business units who need answers rather than raw materials, the consumption-ready Data Marketplace might deliver more value.

Most organizations need elements of all three. The real choice is about boundaries and interfaces. Where does one catalog’s responsibility end and another’s begin?

Perhaps the deepest question is whether cataloging itself remains the right metaphor. Catalogs emerged from static collections—library books, museum artifacts, product inventories arranged on shelves. Data today is fundamentally different. It streams, transforms, exists in multiple representations, disappears.

We might need something less like a catalog and more like a navigation system.

Cataloging assumes pre-indexing what exists; navigation assumes finding paths through what’s changing.

On-demand search for unstructured content, automated lineage that traces backwards from discovery, and recommendation engines driven by actual usage patterns.

The data landscape has expanded far beyond tables; our approach to making it navigable should expand too—not just in scope, but in conception. Sometimes that means better catalogs, sometimes different catalogs for different needs, and sometimes recognizing that not everything needs cataloging.

The paradox resolves when we stop trying to make everything findable and start making the right things findable in the right ways for the right people.

What’s your experience with data catalogs? Have you faced the paradox of comprehensive cataloging creating more noise than signal? I’d love to hear your thoughts in the comments.

The data governance industry has sold a seductive vision: automatic correctness at source. Push the controls upstream, embed them in code, prevent bad data from entering the system. Governance at source, implemented through computational automation. It’s elegant, logical, and deliberately avoiding the hardest question.

By whom?

The Illusion of Objectivity

Data quality isn’t physics. Every validation rule, every data contract, every automated check represents someone’s judgment about what matters and why. The industry has automated the judgment—it hasn’t eliminated the need for it.

Consider a validation rule for customer status. Marketing defines “active” as anyone who’s engaged in the past 90 days. Finance defines it as anyone with a current contract. Operations defines it as anyone who’s received service in the past 30 days. Each perspective is valid for their context. Your automated governance at source must choose one—and that choice, embedded in validation logic, will silently break someone’s business process. Who made that call? Who owns the consequences? Who has authority to question it?

By embedding decisions into code—through data contracts, schema registries, API-first governance—organizations have made these decisions feel objective, inevitable, technical. They’re none of these things. They’re human judgments, frozen in logic, executed at scale, and nobody can be held accountable for them.

Authority Laundering

Traditional governance had clarity. When centralized teams made decisions, you knew where to direct complaints. Origin-based governance distributes this accountability into oblivion.

Developers implement validation logic but aren’t making governance decisions—they’re enforcing schema adherence, optimizing for uptime. Product owners define specifications but aren’t governance experts. Architects design contracts but lack business context. Domain experts understand nuance but can’t override technical constraints.

Everyone is responsible. Which means nobody is responsible.

It’s authority laundering—developers implement “governance logic” from product owners who defer to architects who reference policies from governance teams uninvolved in actual decisions. When something breaks, watch what happens: orders fail silently, customer service blames IT, IT blames the vendor, the vendor points to industry standards. Six months to fix because nobody has clear authority to override the rule, and you can’t fire an algorithm.

The Judgment Dilemma

Correctness at source assumes organizations can know, in advance, what correct means for every business context. Reality collapses this assumption.

Data quality is contextual. A customer address might be “correct” for billing but insufficient for delivery. An incomplete record might be unusable for analytics but acceptable for logging. A value might violate validation rules yet represent genuine business reality those rules failed to anticipate.

Traditional governance: data stewards making human decisions with full context. Computational governance: algorithms executing predefined logic. One is slow, manual, and accountable. The other is fast, automated, and accountable to nobody.

The Dangerous Middle Ground

Most organizations have implemented governance-at-source technically while maintaining centralized governance authority organizationally. Data producers bear responsibility without authority to define standards. Central teams retain authority without proximity to operational reality.

The deadlock gets “resolved” through exception processes, shadow systems, or data marked “quality checked” while bypassing validation.

Organizations have made governance simultaneously more rigid and more avoidable.

What Courage Demands

Real governance at source requires clear authority matched with accountability, distributed to those with domain knowledge. This means product teams implementing validation must have genuine authority to define quality standards for their domain. Domain experts must have mechanisms to challenge automated decisions when business reality contradicts governance logic.

Yet naming this reveals the courage most organizations lack. Distributing authority means accepting different domains might define quality differently, trusting judgment over process, acknowledging that rigid consistency may matter less than contextual correctness. The enterprise would rather automate than trust, centralize authority while distributing blame, build sophisticated validation logic than confront who should make validation decisions.

The Test

Can you name, specifically, who has authority to change the validation rule that’s causing business problems? Not “the governance team” or “the data quality council.” An actual person, with clear authority, who can decide and own consequences.

If you can’t name them, you don’t have governance. You have governance theater, with automation performing the role of accountability.

Perhaps that’s the point. Computational governance succeeds precisely because it obscures accountability—nobody wants to own difficult judgment calls. But governance without authority isn’t governance. It’s compliance theater with better production values.

The most revealing moment comes when someone says “the system rejected it.” As if the system made a choice. As if accountability could be delegated to logic.

But here’s the provocation: compliance is a symptom, not a goal.

Subscribe now

When governance succeeds, you don’t see better compliance metrics—you see faster decisions, more reliable operations, and teams that trust their data without thinking about it.

Organizations obsessed with compliance inadvertently reveal their operating philosophy. They’re still living in a world where success means control—where the role of governance is to prevent bad things from happening. This defensive posture creates the very friction that guarantees resistance. When governance is framed as protection, it implies threat. When it implies threat, people build workarounds.

The alternative isn’t abandoning governance—it’s reframing what success looks like.

The question isn’t whether people followed the data classification policy. It’s whether the marketing team launched their campaign faster because they trusted their customer data. It’s whether operations ran smoother because quality issues didn’t cascade through systems. It’s whether executives made better decisions because they didn’t have to question the numbers.

This isn’t semantic games. The metrics you choose shape the systems you build. Organizations measuring compliance build oversight mechanisms. Organizations measuring speed build enabling infrastructure. The former creates governance as tax; the latter creates governance as accelerant.

The most dangerous assumption in data governance is that if everyone follows the rules, good outcomes will follow. In reality, the causation runs the other way. When governance creates genuinely better outcomes, following the rules becomes the rational choice—not because it’s mandated, but because it works.

Stop asking whether people comply. Start asking whether they’re winning.

Read more:

This isn’t about competence or intention. Governance enthusiasts are typically brilliant, deeply knowledgeable, and genuinely committed to protecting the organization. That’s precisely the problem. They design governance for people like themselves—those who find joy in comprehensive frameworks, who see elegance in detailed taxonomies, who believe deeply in governance’s transformative power.

Subscribe now

But governance enthusiasts represent a small fraction of the organization. The vast majority have a radically different relationship with data. They don’t want to understand governance; they want to finish their quarterly report. They don’t care about metadata standards; they care about whether they can trust the numbers in front of them.

When governance enthusiasts build elaborate cathedrals of compliance, most people are just looking for a door.

The result is predictable. Governance teams celebrate comprehensive coverage while business users celebrate creative workarounds. Two groups, both succeeding by their own metrics, while the organization fails at the only metric that matters: whether governed behavior actually happens.

The shift required isn’t technical—it’s philosophical. Governance must stop being designed by enthusiasts for enthusiasts and start being designed as a product that serves reluctant users. Think of it like a bridge: the architect may appreciate its structural integrity, but pedestrians just want to cross without thinking about load-bearing calculations.

When governance becomes invisible infrastructure rather than visible overhead, something remarkable happens. People adopt it not because they’re told to, but because it makes their work easier. Compliance becomes a byproduct of convenience, not the outcome of coercion.

The hardest conversation your governance team needs to have is with itself:

Are we building this for us, or for everyone else?

Read More:

Your data governance initiative just hit its first anniversary. The stewards are trained and metrics look perfect. So why is everyone still swimming? Teams beyond the pilot still view governance as "someone else's problem"—a distant corporate directive. Shadow data practices persist, despite "governed" alternatives existing.

This common scenario reveals the critical misstep: treating data governance as a technology rollout, not a strategic transformation. The challenge most enterprises experience with data governance implementation follows the same patterns Geoffrey Moore identified in his innovation adoption framework—there's a treacherous chasm between initial success with "innovators" and lasting enterprise-wide impact with the mainstream majority. While Martin Eriksson recent analysis (The Decision Stack's : "Crossing the Chasm Inside Your Organization") provides a framework for understanding the chasm, we can see that this chasm also is amplified by the broader paradigm shift in the organization that is underway and rapidly gaining momentum

As enterprises embrace product-oriented thinking, AI-driven operations, and empowered team structures, the friction between old and new operating models amplifies the data governance adoption challenge. This emerges from a fundamental collision between two organizational paradigms:

LegacyCo thinking is characterized by measuring success through control and efficient execution, which leads to a prioritization of process compliance and hierarchical approval.

NewCo thinking, conversely, measures success by rapid learning and autonomous execution, focusing on distributed judgment within automated boundaries.

Most governance initiatives, designed with a LegacyCo mindset for NewCo behaviors, create the very friction that prevents widespread adoption. This paradigm mismatch is why so many well-intentioned efforts stall in pilot purgatory.

The Governance Enthusiasts vs. The Pragmatic Majority

Traditional governance excels with "governance innovators"—data stewards, platform engineers, and compliance teams who grasp governance's strategic value. These enthusiasts champion frameworks, embrace training, and believe in its transformative power. Their pilots prove it: measurable gains in data quality, faster compliance, reduced risk exposure.

But then comes the chasm.

The pragmatic majority isn't a monolithic group—they represent distinct audiences with fundamentally different needs. The Early Majority—middle managers and team leads—require concrete frameworks and decision-making criteria they can apply. They want to understand not just the vision but how governance translates into daily priorities and trade-offs. The Late Majority—frontline analysts and operational staff—demand even more specificity: explicit processes, clear expectations, and step-by-step guidance integrated into their existing workflows.

This segmentation reveals why one-size-fits-all governance communication fails. When governance leaders present high-level strategic vision to pragmatic managers drowning in quarterly deliverables, the disconnect is inevitable. The divide deepens through a persistent language barrier, where governance enthusiasts speak in technical vocabularies that feel abstract and bureaucratic, reinforcing a powerful "us versus them" dynamic.

When governance feels like added overhead rather than value creation, the pragmatic majority, driven by immediate operational pressures, discovers workarounds, exceptions, and alternative paths that bypass the systems designed to help them. This isn't resistance to change—it's rational behavior rooted in LegacyCo thinking, where success is measured by output over percieved abstract compliance. The divide deepens through a persistent language barrier, where governance enthusiasts speak in technical vocabularies that feel abstract and bureaucratic, reinforcing a powerful "us versus them" dynamic.

This rational response creates a predictable pattern: governance systems designed by enthusiasts optimize for compliance completeness, not workflow integration. What feels elegant to a data steward often feels cumbersome to users facing urgent deadlines. The governance team celebrates process compliance while business users celebrate process avoidance—two ships passing in the night, each rowing toward different shores.

Why Traditional Governance Approaches Fall Into the Chasm

Most governance initiatives fail to cross the chasm because they misinterpret what business users actually require and expect. Governance innovators focus on building comprehensive frameworks which work brilliantly for the small percentage naturally wired for governance. However, the pragmatic majority demands something fundamentally different: governance that disappears integrated into their existing workflows rather than adding new steps and layers.

The chasm forms when governance demands behavioral change; effective governance adapts to natural business behavior while achieving the same protective outcomes.

So, what if governance became less a compliance burden, more a bridge that users cross without realizing it?

The Computational Bridge Across the Chasm

This demands a fundamental shift from manual to computational governance—a transition from LegacyCo's centralized judgment with distributed execution to NewCo's distributed judgment within clear, automated boundaries. This is more than process automation; it's an architectural transformation where governance logic moves from external oversight embedded into the operational fabric itself, becoming the invisible infrastructure that holds the bridge together.

Intelligent data infrastructure actively ensures data quality, dynamically applies context-appropriate access controls, and automatically maintains audit trails—all while users focus on creating business value. This approach succeeds with both segments of the pragmatic majority by eliminating adoption friction. The Early Majority discovers their strategic planning becomes more reliable with trusted data foundations, while the Late Majority finds their existing workflows have become more efficient as compliance happens automatically in the background. Instead of learning new processes, both groups experience immediate operational improvements.

Governance at the Source: Preventing Problems Before They Start

True computational governance extends beyond making consumption frictionless; it embeds controls where data is born, anchoring the bridge at its strongest foundation. When data producers—applications, sensors, user interfaces, and collection systems—automatically apply adaptive governance rules at creation, organizations prevent problems rather than detect them downstream. Application development and product teams represent a uniquely powerful segment in this transformation, serving as both data producers through new services and data consumers for feature development. When these teams embrace governance-by-design, they create a virtuous cycle: their applications generate higher-quality, better-documented data that accelerates their own future development while reducing the governance burden on downstream consumers.

This "shift-left" approach resonates powerfully with business users by fundamentally improving operational robustness. Instead of discovering data quality issues weeks later during analysis, they experience more reliable day-to-day operations with clean, compliant data flowing naturally from source systems—like crossing a bridge built on solid bedrock rather than shifting sand. This governance-embedded infrastructure ensures that every data entry point inherently applies appropriate validation, classification, and protection.

The primary value isn't better analytics; it's operational reliability. Processes run smoother as data quality issues don't cascade through systems. Operations become more predictable because governance prevents, rather than detects, problems—the bridge supports everyone's journey rather than forcing detours. Better insights and analytics then emerge as valuable secondary benefits of this robust operational foundation. Teams make decisions faster because they trust their data.

Designing for the Pragmatic Center

The computational bridge succeeds only when governance enthusiasts embrace a fundamental mindset shift: treating data governance as a product and the pragmatic majority as their customers. Like any successful product, governance must solve real user problems—making work easier, faster, and more reliable—rather than optimizing for its internal architecture.

This product mindset demands a layered communication strategy that serves different user needs rather than broadcasting the same message to everyone. The Early Majority requires detailed frameworks for decision-making, concrete examples of governance application, and clear prioritization criteria they can use when facing trade-offs. They need monthly communication and regular reinforcement, not just quarterly updates. The Late Majority demands step-by-step processes, explicit expectations, and governance capabilities embedded directly into their existing tools and workflows.

Business users adopt governance based on direct utility, not theoretical completeness. They evaluate it on whether it simplifies, accelerates, or enhances daily work. The most successful governance transformations deliver immediate workflow improvements that include governance benefits, rather than the reverse.

When a marketing analyst discovers the customer data platform provides faster, higher-quality data than shadow spreadsheets, they adopt it for productivity. The governance outcomes—better data lineage, automated privacy controls, consistent business definitions—emerge as natural byproducts, not added requirements. This adoption pattern reveals the power of embedding governance value into existing user journeys rather than requiring separate governance processes.

Beyond the Pilot: Scaling Governance DNA

Organizations that successfully cross the governance chasm master both the language and mindset transformation. They translate governance value into business vocabulary while simultaneously designing governance capabilities as products that serve real customer needs. This dual shift—from jargon to clarity, from compliance to value—creates the bridge across the chasm.

For organizations bridging the governance chasm, the scaling challenge shifts from technical execution to cultural transformation: moving from ingrained "LegacyCo" coordination engines to "NewCo" learning engines. This cultural embedding happens through "governance by design"—making governance considerations natural to problem-solving, not an afterthought. Product teams automatically consider data privacy implications while designing features; analysts naturally document assumptions and data sources; and engineers default to building auditable, traceable systems. In such environments, governance becomes invisible infrastructure rather than visible overhead.

The transition requires shifting governance from a dedicated function to a distributed, embedded capability. This doesn't eliminate governance specialists, but changes their role from enforcers to enablers—designing systems and frameworks that make governed behavior the path of least resistance. Cultural transformation requires both governance literacy appropriate to each audience and proactive reinforcement that rewards governed behavior rather than merely punishing ungoverned practices.

This governance literacy cannot be achieved through broad communication alone—it demands specialized, hands-on training tailored to each segment's specific context and workflow. Without this specialized enablement, even the most elegantly designed data governance will fail to achieve widespread adoption.

When organizations claim to value governance yet reward speed over compliance, they create competing contingencies that undermine adoption, reinforcing "LegacyCo" patterns. Effective reinforcement transforms governance into a competitive advantage, signaling a true embrace of "NewCo" principles.

This transformation faces a critical challenge: the repetition problem. Data governance enthusiasts, deeply embedded in developing the approach, are ready to move to execution just when the Early Majority is hearing about it for the first time. The temptation to rush past detailed communication because enthusiasts are "tired of talking about it" is exactly how governance initiatives die in the chasm. The Early Majority needs time, repetition, and multiple formats to absorb and internalize governance thinking, while the Late Majority requires even more hands-on support and embedded guidance.

Success requires measuring adoption like any product launch: Can teams describe governance value in their own words? Can they explain not just what to do, but why governance choices matter for their specific context? Do their daily decisions reflect governance thinking without being mandated? Are they making governance-informed trade-offs because they understand the underlying value, not because they're following rules?

Teams mastering automated governance solutions deliver business results faster and more reliably than those relying on manual processes and unofficial data. This performance advantage is reflected in metrics critical to business leaders: improved operational reliability, faster time-to-decision, reduced operational risk, and enhanced process quality.

The Path Forward: From Governance Rhetoric to Governance Reality

Organizations crossing the governance chasm recognize a core truth: the goal isn't perfect compliance, but operational excellence. They measure success not by policy adherence rates, but by business metrics improving with effective governance. This outcome orientation drives them to computational governance, embedding automation into operational data infrastructure rather than overlaying it.

Success requires measuring adoption like any product launch: Can teams describe governance value in their own words? Can they explain not just what to do, but why governance choices matter for their specific context? Do their daily decisions reflect governance thinking without being mandated? Are they making governance-informed trade-offs because they understand the underlying value, not because they're following rules?

The future belongs to organizations mastering this transition. Not because they achieve perfect compliance, but because their governance systems integrate so seamlessly with operational workflows that compliance becomes a natural byproduct of reliable operations, not an added requirement.

The chasm between governance vision and reality is an adoption gap, not a technology one. It is a challenge solved not with mandates or policies for the few, but with systems that serve the practical needs of the many, who ultimately determine the success or failure of any transformation—completing the bridge that allows everyone to cross together, rather than leaving most still swimming.

How quaint.

This perspective couldn't be more outdated if it arrived via fax machine.

Breaking Down the Metaphor

Let's get something straight: guardrails aren't hurdles. They don't exist to slow you down or force conformity. Quite the contrary—guardrails enable you to move faster with confidence.

Picture this: you're driving along a mountain road. Without guardrails, you'd crawl at 15 mph, white-knuckling the steering wheel, terrified of the cliff edge. With proper guardrails? You can appreciate the view while maintaining a reasonable speed, knowing precisely where the safe boundaries lie.

The same applies to data.

Alignment Enables Autonomy

The most innovative organizations understand a fundamental truth: proper alignment is what enables true autonomy.

When everyone understands the parameters, when governance is embedded in processes rather than imposed after the fact, teams don't need to wait for approval from the "data police." They can sprint ahead with confidence, knowing they're operating within safe, established boundaries.

This isn't about forcing people to use data in an "ordinary fashion." It's about creating the conditions for extraordinary innovation by removing uncertainty and establishing clear paths forward.

Computational Governance: The New Frontier

Modern data governance isn't about committee meetings and spreadsheets. It's about embedding governance into the code, into the infrastructure, into the very DNA of how an organization operates.

When governance happens at the point of origin—when it's computational rather than bureaucratic—it becomes invisible. And that invisibility is the hallmark of success.

Not Just Guardrails, But GPS

The future of data governance isn't just about knowing where the edges are—it's about actively guiding teams toward their destination. It's not just about preventing catastrophe; it's about enabling success.

It's the difference between saying "don't go there" and saying "here's the fastest route to your goal."

So while some thought leaders cling to outdated metaphors and frameworks from a bygone era, the rest of us will be over here, building systems where governance enables rather than restricts, where accountability is clear, and where innovation thrives precisely because the guardrails are so well designed.

Because in the end, the goal isn't to create more elaborate governance structures—it's to make governance so seamless, so embedded, that we hardly need to talk about it at all.

Except, perhaps, when correcting outdated metaphors.

Here's the uncomfortable truth:

If your organization needs a separate data governance team with an army of data owners and stewards, you've already failed.

When governance is an afterthought, it's too late, too slow, and way too expensive. By then, your data is already compromised, and your AI initiatives are built on quicksand. In today's AI-driven landscape, this approach isn't just inefficient—it's existentially threatening to your competitive position.

Success at the Source: The Origin Advantage

The magic happens at the point of origin. When data governance is baked into every process from the start, something beautiful emerges:

1. Accuracy becomes automatic rather than corrective, with validations occurring the moment data enters your systems.

2. Business context travels with the data instead of being retrofitted later, preserving the vital meaning that makes data truly valuable.

3. Observability and lineage become inherent rather than investigative, allowing you to understand data flow without complex archaeology projects.

Traditional data governance is like installing safety inspectors at the end of a manufacturing line when the defects were created at the beginning. Computational governance moves quality control to where it belongs—at the point of production.

The most successful data organizations measure their governance success by its invisibility. When governance is working perfectly, dedicated governance roles evolve – not because governance doesn't matter, but because it's become everyone's responsibility, embedded in daily operations rather than siloed in a separate function.

The Governance Paradox

The paradox haunts me: just as organizations finally recognize the strategic importance of data, traditional governance approaches are actively sabotaging their AI future. While governance teams craft elaborate taxonomies and policies, competitors are implementing AI solutions that create actual business value.

Consider this scenario: By the time a governance committee documents the lineage of a problematic dataset, an AI model has already been trained on flawed information, deployed to production, and made thousands of questionable decisions. The damage is done, and remediation is far costlier than prevention.

This paradox emerges because the very structures created to ensure data quality become obstacles to using that data effectively. The larger your dedicated governance team, the stronger the signal that your approach to data quality has fundamentally failed.

We're building castles in the sand when we need fortresses on bedrock.

Computational Governance: The New Paradigm

Imagine a world where data rules are written in code, not committee memos, and compliance is as automatic as breathing. This isn't science fiction—it's the inevitable evolution of data governance.

The key to this transformation is computational governance – embedding requirements directly into the infrastructure where data lives:

• Data quality rules, privacy requirements, and business context are encoded into the very systems that manage data

• Governance happens automatically at the point of creation, not as a separate checkpoint

• Systems enforce data contracts – clear, executable agreements between producers and consumers

Imagine a customer placing an order on your e-commerce platform. Computational governance doesn't just passively accept the data. It automatically validates the shipping address against postal databases, checks inventory availability in real-time, flags potential fraud patterns in the payment details, and ensures the customer's preferences and history are immediately attached to the order. When the marketing team later analyzes purchase patterns, they don't need to hunt down missing context or clean the data—the governance happened the moment the order was placed.

When governance is code rather than committee, it scales with your organization while enabling rather than hindering innovation. This doesn't eliminate human judgment – ethical considerations and evolving requirements still need oversight – but it automates the consistent application of those judgments.

The organizations that thrive in the AI era won't be those with the most elaborate governance frameworks. They'll be those who make governance invisible – embedded so effectively into their operations that it enables innovation rather than constrains it.

Your First Steps Toward Invisible Governance

Forget the endless meetings and bureaucratic jargon. The path forward begins with a fundamental shift in thinking. Rather than building governance kingdoms with elaborate hierarchies of stewards and owners, focus on embedding governance into the fabric of your data systems.

Start by examining one critical data flow in your organization:

• Where does that data originate?

• What quality checks could be embedded right at that point?

• What business context gets lost in transit that could be automatically preserved?

This approach requires collaboration between technical and business teams, but with a crucial difference:

Instead of creating bureaucratic processes, they work together to encode governance into the infrastructure itself.

The AI revolution doesn't need more rules and gatekeepers. It needs smart, computational governance with robust data contracts that enable seamless integration between technical capabilities and business needs.

Remember: Governance at the point of origin isn't just more efficient – it's the only approach that can scale to meet the demands of modern data and AI systems.

Let's stop treating data governance like it's special and start treating it like it's essential.

The true mark of governance success isn't a growing team of data stewards—it's their evolution, as quality becomes intrinsic to how your organization creates and consumes data.

Are you ready to code your future, or are you content to be a spectator in the AI revolution?