Federated Computational Governance

Federated computational governance is the governance model proposed as part of data mesh: domains hold decision-making authority over their own data, a small set of rules applies to everyone to keep the results interoperable, and the platform enforces those rules automatically rather than asking teams to comply. Zhamak Dehghani names the three parts together — the model requires “decentralization and domain self-sovereignty, interoperability through global standardization, a dynamic topology and most importantly automated execution of decisions by the platform.” Descriptions follow that article, checked in September 2026.

Who is in the federation

The decision-making body is described precisely: “a decision making model led by the federation of domain data product owners and data platform product owners, with autonomy and domain-local decision making power, while creating and adhering to a set of global rules — rules applied to all data products and their interfaces — to ensure a healthy and interoperable ecosystem.”

Two details in that sentence are easy to skip and both matter. The people who own the data products are the ones making the global rules, rather than a separate body making rules for them — which is what keeps the rules implementable. And the platform’s owners are in the room, because a rule that the platform cannot enforce is a rule that will not hold.

The hard part is the boundary

Dehghani calls the group’s task “maintaining an equilibrium between centralization and decentralization; what decisions need to be localized to each domain and what decisions should be made globally for all domains,” and states the purpose of the global half plainly: global decisions exist for “creating interoperability and a compounding network effect through discovery and composition of data products.”

That gives a usable test for what belongs on the global list. A rule earns its place if leaving it local would stop two domains’ data from being used together — identifier formats, classification and access standards, the obligation to publish a contract and to register in the catalog. A rule fails the test if it merely expresses a preference about how a domain works internally. The article’s own example of a local concern is the domain data model, “a concern that should be localized to a domain who is most intimately familiar with it.”

Keeping that list short is not tidiness. Every global rule is something every domain must wait for and comply with, so a long list reproduces the bottleneck the model was adopted to avoid.

Why “computational” is load-bearing

In a centralized model, a rule can be enforced by a team that reviews things. A federated model has no such team, which is why the automation is not an efficiency feature but the enforcement mechanism: rules are “baked computationally into the platform,” and the model depends on “automated execution of decisions by the platform.” Expressed as executable checks — policy as code — a rule holds without anyone remembering it.

Without that half, what remains is a committee issuing guidance to teams who do not report to it, which is the most common way this model is adopted and the most common way it fails.

What it is reacting against, and what it costs

The contrast is stated explicitly: traditional governance of analytical data pursues value “through centralization of decision making, and establishing global canonical representation of data with minimal support for change,” while this model “embraces change and multiple interpretive contexts.” Accepting multiple interpretations is the substantive shift — two domains may legitimately define a customer differently, and the governance job becomes making both definitions discoverable and joinable rather than eliminating one.

The costs are real and worth naming before adopting the label. The model needs “a supportive organizational structure, incentive model and architecture” — domains must be resourced to own data products, not merely told to. It needs a platform capable of enforcing rules automatically, which is engineering work that precedes the governance benefit. And it needs someone to keep the global boundary written down, because an unwritten boundary is renegotiated in every meeting.

A reasonable adoption order follows from that: agree the first two or three global rules, implement their automated checks, and only then invite domains to own their data products — rather than announcing federation and discovering that nothing enforces anything. How this model compares with centralized and fully domain-owned arrangements is worked through in Who Decides What; the authority it distributes is covered in decision rights.

Reference: Zhamak Dehghani, Data Mesh Principles and Logical Architecture.