Abstract

Data mesh decentralizes data ownership to domain teams but concentrates organizational risk in the governance layer that bridges those domains. Federated computational governance - the approach in which policies are expressed as code, versioned centrally, and evaluated locally within each domain - attempts to resolve this tension. The mechanics of making it work across heterogeneous compute platforms, catalogs, and identity systems remain underspecified in most published implementations. This post examines the policy-as-code substrate, the role of open policy frameworks like Open Policy Agent and Cedar, and the integration points that matter most when domains run on different cloud providers or engine stacks.

Policy as Code and the Separation of Definition from Evaluation

Governance policies in a federated model must be defined centrally (to ensure consistency) but evaluated locally (to avoid the latency and availability risk of a central enforcement proxy). Open Policy Agent (OPA) achieves this through its Rego language and the bundle distribution mechanism: policies are compiled into bundles, distributed to each domain’s enforcement sidecar, and evaluated in-process at decision time. AWS Cedar, released in 2023 and gaining adoption in enterprise data platforms through 2025, uses a different model - a purpose-built policy language with provably correct authorization semantics. Cedar’s validation guarantees are stronger than OPA’s Rego at the cost of a more constrained expression language. For data mesh deployments, the choice between them is partly a trust question: OPA’s flexibility means a misconfigured policy can permit more than intended; Cedar’s constraints make certain classes of mistakes impossible.

Column-Level and Row-Level Policy Expression

Table-level access control is insufficient for most real data mesh deployments: different consumers need different views of the same asset, and those views are defined by column-level sensitivity classifications and row-level predicates based on consumer identity or purpose attributes. Expressing these policies in a way that is both human-readable and machine-evaluable requires a policy schema that maps data product attributes to access rules. The DataHub and Amundsen open governance extensions encode sensitivity labels as metadata that policy evaluation can reference. Unity Catalog’s attribute-based access control model does the same within the Databricks ecosystem, but cross-platform portability requires translating those labels into a neutral schema that OPA or Cedar can evaluate against any compute engine.

Cross-Domain Query Tracing and Compliance

When a query crosses domain boundaries - a downstream analytics domain joining against a sensitive HR or finance product - the lineage record must capture both the data-product identity and the policy evaluation outcome at the time of access. This is not simply a lineage problem but an audit problem: the policy that permitted access at query time may change, and a compliance audit may require demonstrating that access was permitted by the policy version in effect at a specific timestamp. Immutable policy version history, combined with query-time snapshots of the evaluation result, is the minimum record needed. Marquez and OpenLineage support attaching custom facets to run events, which is the integration point for encoding policy evaluation metadata alongside the standard lineage.

Practical Gap Between Principle and Implementation

Few organizations that have adopted data mesh have implemented federated governance at the column and row level across multiple compute platforms. The pattern more commonly observed is table-level governance enforced at the catalog, with column masking delegated to compute-layer views that vary by domain. This is operationally simpler but produces inconsistent policy application: a column classified as PII in one domain’s catalog may be unmasked in another’s query output if the view was built before the classification was applied. Closing this gap requires treating policy evaluation as a first-class concern at the data product API layer, not an afterthought applied at the storage tier.