Federated computational governance: rules as code, not as a committee

Global, because interoperability breaks without it: the identifiers domains join on (customer_id, order_id) and their format, the privacy classification vocabulary and what each level permits, the naming and addressing convention for output ports, the minimum quality bar every published product must clear, and the retention rules that come from law rather than preference.

Local, because centralizing it creates the queue you are trying to remove: the internal model of each domain, transformation logic and its tests, the schedule, the exact service level a product promises above the minimum, and the shape of consumer-aligned products.

The test for a candidate rule: would breaking it hurt another domain. If yes, it is global. If it only hurts the owning domain, it is a local standard and belongs in that domain's code review, not in the policy repository. Governance bodies grow bureaucratic by failing this test in one direction only.

A policy that a human checks during a review is not computational governance; it is a review checklist with a new name. The working version is a policy repository whose rules run as code in three places: in the domain CI pipeline before a data product deploys, in the platform at provisioning time, and continuously against published products so drift is caught rather than assumed away.

Open Policy Agent with Rego is the common choice, because the same engine already guards Kubernetes and Terraform in most platform teams, so the governance rules land in machinery that exists. The unit under evaluation is the data product descriptor: its classification, its ports, its owner, its access policy.

Write against Rego v1, and check which version any example you copy came from. OPA 1.0, released on 20 December 2024, made if mandatory on every rule definition and contains mandatory on multi-value rules, so a policy lifted from a 2023 post fails to parse before it evaluates anything. The block below is v1 syntax.

The corresponding gate for schema and quality is the data contract check, run in the same pipeline. The two together cover most of a global policy set: the policy engine answers "is this product allowed to exist in this shape", and the contract check answers "does the data match what was promised".

package datamesh.policy

# Global rule: nothing classified pii may expose an unmasked output port
deny contains msg if {
  some port in input.output_ports
  input.classification == "pii"
  not port.masking
  msg := sprintf("%s: output port %s exposes PII without masking", [input.name, port.name])
}

# Global rule: every published product names an owning team
deny contains msg if {
  not input.owner
  msg := sprintf("%s: no owner declared", [input.name])
}

Three call sites, in order of how early they catch a problem. In the domain pull request, so the author sees the failure next to the change that caused it. At provisioning time in the platform, so a product cannot be deployed into a shape the policy forbids. And on a schedule against everything already published, because a rule added in March says nothing about the products that shipped in February.

The third is the one teams skip, and it is the one that makes the policy set honest. Evaluate every descriptor in the catalog nightly and publish the failure count per domain. A rule that has never been run against the existing estate is a rule you have only asserted.

Keep the policies under test like any other code. Rego ships a test runner, so a rule and its counterexample live in the same repository and a governance decision arrives with evidence that it does what the forum agreed rather than what its author assumed.

# In the domain pull request: does this product descriptor pass?
opa eval --format pretty \
  --data policy/ --input products/checkout/orders.json \
  'data.datamesh.policy.deny'

# In the policy repo's own CI: do the rules do what the forum agreed?
opa test policy/ -v

# Nightly, across everything already published:
for f in catalog/*/*.json; do
  opa eval --format raw --data policy/ --input "$f" \
    'count(data.datamesh.policy.deny)' | grep -qx 0 || echo "FAIL $f"
done

The forum is small: one representative per domain who can commit their team, plus platform and one legal or privacy voice. It meets on a fixed cadence, and its output is a merged pull request in the policy repository, never a document. A governance group whose decisions do not become code has been given responsibility without authority, which is the usual shape of the failure.

Two mechanics keep it from turning into bureaucracy. First, default to allow: a rule enters the policy repository only when a concrete incident or an interoperability need justifies it, and every rule carries the reason in a comment. Second, give domains an exception path with an expiry date, so an urgent product ships with a recorded, time-boxed waiver instead of a quiet violation.

Measure the forum by the number of policies enforced automatically versus the number enforced by asking. If the second number is not falling, the computational half is not happening.

Three feeds make automated governance possible: a catalog holding every product with its classification and owner, lineage down to the column so an access decision on one field can be traced to everything derived from it, and quality results as measured values rather than as green ticks.

The visual companion matters more than governance leads expect. A picture that shows which domain publishes what, and which domain consumes it, resolves the majority of classification questions before anyone opens the catalog. Datadef draws that plane with column-level lineage on the canvas, and the diagram regenerates from the connected repository on a daily sync so the governance view does not quietly age out. See also data lineage best practices.

• Data governance framework
• The four principles of data mesh
• Data catalog best practices
• Data lineage best practices