Data mesh governance connects domain ownership to shared rules that teams can apply, test, and review. For a consumer, that connection should be visible in a practical outcome: the application receives the data it is allowed to use, through a delivery path that checks its permissions.
Consider an application requesting five fields from a customer-status product. The owner approves three. If the response still contains all five, the approval exists on paper but has not changed delivery. If the application receives nothing because partial approval cannot be implemented, the workflow needs a clearer contract.
This guide shows how to design that connection, using a worked example, a responsibility map, and a rollout checklist. The example is an architecture pattern; it is not a customer case study or a claim that every implementation behaves the same way.
What does federated data mesh governance mean?
In Zhamak Dehghani’s original data mesh principles, federated computational governance sits alongside domain ownership, data as a product, and a self-service platform. The model combines shared standards with decisions made close to the domain, supported by computational policies. Its original focus is analytical data.
For the access workflow below, the design question is specific: how can a domain approve a consumer’s use while the platform applies the agreed rules consistently? API delivery is one possible interface. A data mesh does not require every product to use the same serving technology.
For the broader ownership and policy context, start with our guide to data governance.
Decide what is shared and what belongs to the domain
A practical implementation needs a decision map. Use the following split as a starting template, then adapt it to the organization’s responsibilities and risk requirements.
| Decision area | Shared baseline | Domain or product decision |
|---|---|---|
| Identity | How applications and people are identified and authenticated. | Which named consumers need this product for an agreed purpose. |
| Data classification | Common classification labels and handling rules. | How the product’s fields are classified and documented. |
| Access approval | Required request information, expiry rules, and exception handling. | Which requested fields to approve within the shared baseline. |
| Delivery and evidence | Minimum enforcement and evidence requirements. | Product interface, freshness expectations, and consumer support. |
The baseline should leave enough room for domain knowledge. A central team may define how sensitive fields are handled; the product owner still needs to understand whether a consumer’s task requires a particular field. Exceptions need an explicit owner, reason, and review date.
Give each part of the access decision an owner
A policy becomes difficult to operate when “the governance team” owns every action without clear responsibility for the product or its delivery. A workable responsibility map separates these jobs:
- Data product owner: explains the product’s meaning, intended consumers, field classifications, and approved uses; makes or delegates the product access decision.
- Platform team: provides the request, grant, identity, enforcement, and evidence mechanisms; verifies that the delivery path applies the current decision.
- Governance and security specialists: define shared requirements with domain and platform representatives, advise on exceptions, and review the design.
- Consumer application owner: supplies the purpose and requested fields, protects credentials, follows the agreed contract, and reports changes in use.
Use our data access management guide to place these responsibilities across discovery, approval, consumption, review, and revocation.
Worked example: request five fields, approve three, serve three
All identities, data values, and decisions in this example are synthetic. The response contract deliberately supports partial approval.
A service analytics application needs customer-level account status by region for an internal reporting task. It requests the Customer Account Status product. The owner checks the purpose and decides that contact and identity-document fields are unnecessary.
1. Capture a request that can be reviewed
- Consumer: the named application
service-analytics, with an accountable application owner. - Purpose: reconcile account-status records and produce regional status reports.
- Product: Customer Account Status, with a documented schema and freshness expectation.
- Requested fields:
customer_id,account_status,service_region,email, andnational_id. - Duration: a proposed 30-day grant, followed by an owner review before renewal.
The purpose needs enough detail to support the decision. “For analytics” alone does not explain why the application needs an email address or an identity-document number.
2. Record the field decision and its reason
| Requested field | Decision | Reason for this example |
|---|---|---|
| customer_id | Approve | Reconcile records and avoid duplicate counting. |
| account_status | Approve | Identify the status used in the report. |
| service_region | Approve | Group records by the reporting region. |
| Exclude | The task does not involve contacting customers. | |
| national_id | Exclude | The task does not require identity-document verification. |
An approved field is not automatically harmless. The owner still evaluates classification, purpose, duration, and handling. Here, approval means the field is allowed for this consumer under the example’s agreed conditions.
3. Apply the grant at the delivery boundary
Before returning data, the serving path checks the caller’s identity, target product, active grant, and permitted fields. The response below contains only the three approved fields:
{
"customer_id": "C-1042",
"account_status": "active",
"service_region": "central"
}The excluded fields are absent. That differs from returning every field and hiding columns in the consumer’s interface. It also differs from masking a value. See our field-level security guide for those control boundaries.
Document how the interface handles a request containing unapproved fields. It may return the permitted subset, as this example does, or reject the request. Consumers need a stable contract rather than an unexpected response shape.
Test the policy and keep useful evidence
A successful request is only one test. Validate the cases that show whether the decision is applied when the consumer, grant, or schema changes.
| Test | Expected result for this design |
|---|---|
| Approved application requests the allowed fields | Return only the approved field set. |
| The request includes email or national_id | Exclude those fields or reject the request, according to the documented contract. |
| A different application uses its own identity | Evaluate its own grant; do not inherit the first application’s permission. |
| The grant expires or is revoked | Prevent further access once the current decision is enforced; measure any propagation delay. |
| A nested object or new field is added | Check it explicitly against the permission rules before release. |
For evidence, connect the request, approval, grant, and consumption events using a correlation identifier. A useful record identifies the consumer, product, decision time, relevant policy or grant version, permitted field names, and result. Define retention and access to those records. Avoid logging unnecessary sensitive payload values.
Cached responses and alternate interfaces need the same review. Revocation can stop future access at controlled delivery points; it does not automatically erase data already delivered to a consumer. Those copies need agreed downstream handling.
Start with one product and one real consumer
Use a small rollout to check that policy, ownership, and delivery agree before expanding across domains:
- Select a product with an identifiable owner and a consumer task worth supporting.
- Document its schema, classifications, freshness expectation, and intended delivery interface.
- Agree the shared rules and the decisions the domain can make.
- Run a request through approval, field selection, delivery, and expiry.
- Test permitted and denied cases, including alternate identities and delivery paths.
- Review request turnaround, consumer success, policy exceptions, and the evidence available.
- Use what the pilot reveals to improve the workflow before adding more products.
A governed internal data marketplace can make products and access workflows easier to find. The implementation still needs clear owners, enforceable decisions, and a delivery contract consumers can rely on.
Bring the access decision into an Elementrix demo
Elementrix focuses on governed data products and field-level data access. Bring one product, one application, and a proposed field list to the demo. Use the scenario above to review how a request, approval, and delivered response connect, and which parts fit your environment.