Preventing Chaos Without Creating a New Bottleneck
Decentralization without coordination produces silos. If every team builds whatever they want, you end up with incompatible data: Sales uses user_id as an integer, Support uses email as the primary key, and Shipping uses a legacy customer_code string. Joining these datasets becomes an archaeology project.
But the solution cannot be a Central Governance Committee that reviews every schema change — that recreates the bottleneck you just eliminated.
Federated Computational Governance solves this with two ideas working together:
- Federated: Governance decisions are made by a council of representatives from each domain, not by a central authority. Each domain has a voice. Policies are negotiated, not dictated.
- Computational: Once agreed upon, policies are encoded into the platform and enforced automatically by code — not by a PDF document, a Confluence page, or a quarterly audit.
What Gets Governed Globally vs. Locally
Not everything needs to be standardized. The governance model distinguishes between global standards (mandatory for interoperability) and local decisions (left to each domain).
| Scope | Examples |
|---|---|
| Global (mandatory) | Primary key formats (customer_uuid as UUID v4), timestamp format (ISO 8601 UTC), PII handling policies, data retention minimums, schema registration requirement |
| Local (domain choice) | Internal column naming, transformation logic, pipeline technology (dbt vs. Spark), refresh frequency beyond the minimum SLA |
Computational Enforcement in Practice
"Computational governance" means the platform rejects non-compliant Data Products at publish time, the same way a CI/CD pipeline rejects code that fails tests. Examples:
- Schema validation: The platform checks that every Data Product schema is registered and that all join keys use the global
customer_uuidformat. A product that usescust_idas an integer fails the publish check. - PII detection: An automated scanner (e.g., using AWS Macie or a custom classifier) flags columns containing email addresses or phone numbers and enforces that they are declared in the
pii_columnslist and masked for unauthorized consumers. - SLO enforcement: If a Data Product's freshness SLA is 24 hours and the pipeline hasn't run in 26 hours, the platform automatically marks the product as degraded in the catalog and notifies the owning team.
- Access policy templates: Instead of writing IAM policies from scratch, teams select from pre-approved policy templates. The platform generates the actual policy, ensuring it conforms to security standards.
Why "Computational" Is the Critical Word
The history of data governance is littered with well-intentioned policy documents that nobody follows because there is no enforcement mechanism. The word "computational" is doing heavy lifting here: it means the policy is a function, not a suggestion. If your platform cannot enforce a policy automatically, that policy does not exist in practice. This is the same philosophy behind Infrastructure as Code and Policy as Code (tools like Open Policy Agent) — human review doesn't scale, automated enforcement does.
Interviewers sometimes ask: "How do you balance autonomy and standardization in a Data Mesh?" The answer is the global/local split: standardize only what is necessary for interoperability (join keys, timestamp formats, PII handling, schema registration), and leave everything else to the domain team's discretion. The platform enforces the global standards computationally at publish time, so teams have full autonomy within those guardrails. This mirrors how Kubernetes enforces resource limits and network policies while leaving application logic entirely to the developer.