# Data Mesh Design: [Organisation or data estate]

> Architecture design for a data mesh: the decision that a mesh fits,
> the domains that own data, the data products they publish, the
> self-serve data platform that makes publishing cheap, the federated
> computational governance that keeps products interoperable, the
> interoperability standards, the logical architecture, the operating
> model, metrics and the adoption roadmap. The structure follows the four
> data mesh principles named by Zhamak Dehghani (martinfowler.com,
> 2020), cited by name only. Product and contract metadata use the Bitol
> Open Data Product Standard (ODPS) v1.1.0 and Open Data Contract
> Standard (ODCS) v3.2.0 through the linked templates. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one design per organisation or per large data estate. Each data
  product then gets its own specification (`data/data-product-specification`)
  and each output port its own contract (`data/data-contract`).
- Work in this order: 1 (does a mesh fit) -> 2 (current state) -> 3
  (domains) -> 4 (data products) -> 5 (platform) -> 6 (governance) -> 7
  (standards) -> 8 (logical architecture) -> 9 to 12 (operating model,
  metrics, roadmap, risks) -> 13 (decisions and traceability).
- The decision rights, roles and RACI live in the Data Governance
  Operating Model (`data/data-governance-operating-model`). This design
  references them instead of repeating them.
- The worked examples use Corvid Commerce, a fictional SaaS retailer with
  an Apache Iceberg lakehouse, the same company used in the data product
  and data contract templates. Delete the examples once your rows exist.
-->

## Document control

<!-- Guidance: Identify the estate, the accountable executive and the governance body that approves the design. A new domain or a change to a global policy is a new minor version; a change of platform or principle is a major version. -->

| Field | Value |
|---|---|
| Document ID | [DMD-001] |
| Organisation or data estate | [Corvid Commerce analytical estate] |
| Accountable executive | [@chief-data-officer] |
| Design authority | [@data-architect] |
| Platform owner | [@data-platform-lead] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Approvers/reviewers | [@cdo], [@chief-architect], [@ciso], [@domain-leads] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Governance model reference | [`data/data-governance-operating-model` document ID and version] |
| Standards versions | ODPS [v1.1.0], ODCS [v3.2.0], lineage [OpenLineage version] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Accountable executive | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Data governance council chair | [@name] | [Decision] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Domain leads (each pilot domain) | [@names] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft after fit assessment |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Domain map agreed with Sales, Fulfilment and Finance |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Global policies and platform capabilities approved for the pilot |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose, drivers and fit](#1-purpose-drivers-and-fit)
2. [Current state](#2-current-state)
3. [Domain-oriented ownership](#3-domain-oriented-ownership)
4. [Data as a product](#4-data-as-a-product)
5. [Self-serve data platform](#5-self-serve-data-platform)
6. [Federated computational governance](#6-federated-computational-governance)
7. [Interoperability standards](#7-interoperability-standards)
8. [Logical architecture](#8-logical-architecture)
9. [Operating model and teams](#9-operating-model-and-teams)
10. [Metrics and economics](#10-metrics-and-economics)
11. [Adoption roadmap](#11-adoption-roadmap)
12. [Risks and anti-patterns](#12-risks-and-anti-patterns)
13. [Decisions and traceability](#13-decisions-and-traceability)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose, drivers and fit

<!-- Guidance: Explain why the organisation considers a mesh and test whether it fits. Questions to answer: is the central data team the bottleneck, are domains able to own data, is there enough scale to justify a platform? Pitfall: adopting a mesh because it is fashionable when one central team serving a few consumers would work better. -->

### 1.1 Drivers

| ID | Driver | Evidence | Owner |
|---|---|---|---|
| DRV-01 *(Example)* | Central data team backlog delays new datasets | Median 34 days from request to first usable dataset over the last two quarters | [@cdo] |
| DRV-02 *(Example)* | Analysts do not trust shared tables | Three incidents last quarter where finance and sales reported different order counts | [@head-of-finance] |
| DRV-03 *(Example)* | Domain teams already own operational systems end to end | Six product teams with on-call for their services | [@cto] |
| DRV-[NN] | [Driver] | [Evidence] | [@owner] |

### 1.2 Fit assessment

A mesh moves data ownership to the teams that know the data. That has a
cost: every domain needs data skills, and the organisation needs a
platform and shared standards. Answer each question with evidence.

| Question | Answer | Evidence | Fit signal |
|---|---|---|---|
| Are there several distinct business domains producing analytical data? | [Yes / No] | [Domain list] | Mesh fits better with more domains |
| Is the central team the main bottleneck rather than data quality at source? | [Yes / No] | [Backlog data] | Bottleneck at the centre supports a mesh |
| Can domain teams take on data product ownership with funding and skills? | [Yes / No / Partly] | [Staffing plan] | No means start with a central team and domain stewards |
| Is there budget for a platform team for at least two years? | [Yes / No] | [Budget line] | No platform means each domain rebuilds the same tooling |
| Do leaders accept global policies enforced automatically? | [Yes / No] | [Council minutes] | Without this, the mesh becomes isolated silos |

*Example:* Corvid Commerce answers yes to four questions and "partly" to
domain skills. It adopts the mesh for three pilot domains and keeps a
central team for the remaining three until their skills plan is funded.

### 1.3 Out of scope

[Operational databases, transactional integration (see
`architecture/integration-design`), master data management (see
`architecture/master-data-management-design`), and any area left
centrally managed.]

## 2. Current state

<!-- Guidance: Describe where data lives today, who changes it and what breaks. Questions to answer: which pipelines are central, which datasets have owners, where are the quality and access problems? Pitfall: skipping the current state and designing a target that cannot be reached from it. -->

| Area | Current state | Problem | Evidence |
|---|---|---|---|
| Storage and compute *(Example)* | Lakehouse on Apache Iceberg tables in one cloud account | Shared namespace, unclear ownership of 610 tables | Catalogue export |
| Transformation *(Example)* | One dbt project with 900 models owned by the central team | Changes queue behind each other | Pull request lead time |
| Access *(Example)* | Ticket-based grants by the central team | Two to five days per grant | Ticket data |
| Quality *(Example)* | Tests on some models, no published service levels | Consumers find issues first | Incident log |
| Metadata *(Example)* | Catalogue populated by crawler, few descriptions | Low discovery | Search analytics |
| [Area] | [State] | [Problem] | [Evidence] |

Link the platform baseline to `architecture/data-platform-architecture`
if one exists.

## 3. Domain-oriented ownership

<!-- Guidance: Decide which domains own which data, using business domains rather than technical layers. Questions to answer: which team knows the meaning of the data, which team changes the source, where are the boundaries between domains? Pitfall: creating an "ingestion domain" or "reporting domain", which recreates the central pipeline under a new name. -->

The first principle moves ownership of analytical data to the business
domains closest to it. Use the bounded contexts from domain-driven
design where they exist (`architecture/context-map`,
`architecture/bounded-context-canvas`), so operational and analytical
ownership line up.

### 3.1 Domain map

| Domain ID | Domain | Owning team | Bounded contexts | Source systems | Data product owner | Mesh status |
|---|---|---|---|---|---|---|
| DOM-01 *(Example)* | Sales | Checkout team | Ordering, Payments | Order service, payment gateway events | [@sales-dpo] | Pilot |
| DOM-02 *(Example)* | Catalogue | Catalogue team | Product information, Pricing | Product service | [@catalogue-dpo] | Wave 2 |
| DOM-03 *(Example)* | Fulfilment | Fulfilment team | Warehousing, Shipping | Warehouse system, carrier events | [@fulfilment-dpo] | Pilot |
| DOM-04 *(Example)* | Customer | Accounts team | Identity, Profiles | Account service | [@customer-dpo] | Wave 2 |
| DOM-05 *(Example)* | Finance | Finance systems team | Ledger, Billing | ERP, billing service | [@finance-dpo] | Pilot |
| DOM-06 *(Example)* | Marketing | Growth team | Campaigns, Attribution | Marketing tools | [@marketing-dpo] | Central for now |
| DOM-[NN] | [Domain] | [Team] | [Contexts] | [Sources] | [@owner] | [Status] |

### 3.2 Ownership rules

| Rule ID | Rule | Rationale |
|---|---|---|
| OWN-01 *(Example)* | The team that changes a source system owns the source-aligned products built from it | Changes and meaning stay with the people who cause them |
| OWN-02 *(Example)* | Aggregate products are owned by the domain that uses them most, or by a named consumer-aligned team | Avoids orphaned cross-domain tables |
| OWN-03 *(Example)* | Every product has one accountable data product owner; shared ownership is not allowed | Clear escalation |
| OWN-[NN] | [Rule] | [Rationale] |

## 4. Data as a product

<!-- Guidance: Define what qualifies as a data product, list the planned products and the qualities each must show. Questions to answer: who are the consumers, which ports do they use, what promises does each product make? Pitfall: renaming every table as a product without owners, contracts or service levels. -->

The second principle treats each published dataset as a product with
consumers, a roadmap, quality promises and an owner. Dehghani's 2019
article names qualities such as discoverable, addressable, trustworthy,
self-describing, interoperable and secure; the 2020 article adds
understandability and explorability, and the book (2022) extends the
list with natively accessible and valuable on its own. The table below
uses those quality names with original acceptance tests. Specify each product in
`data/data-product-specification` and each output port in
`data/data-contract`.

### 4.1 Product qualities and acceptance tests

| Quality | Acceptance test for a product to go live |
|---|---|
| Discoverable | Listed in the catalogue with description, owner, domain and tags; appears in search for its business terms |
| Addressable | Each output port has a stable, versioned identifier and location |
| Understandable (self-describing) | Every property has a description; business terms link to the glossary; at least one example query |
| Trustworthy | Published service levels (freshness, availability) and quality checks run on every load, results visible to consumers |
| Natively accessible | Readable through at least one port suited to its main consumers (SQL table, file, API or stream) |
| Interoperable | Uses the global identifiers, time zone, currency and code lists in section 7 |
| Secure | Access by policy from classification; personal data masked by default |
| Valuable on its own | At least one named consumer and use case before build starts |

### 4.2 Product inventory

| Product ID | Product | Domain | Type | Output ports | Contract IDs | Named consumers | Status |
|---|---|---|---|---|---|---|---|
| DP-SAL-01 *(Example)* | Orders | DOM-01 | Source aligned | `orders` 2.1.0 (Iceberg table) | `corvid-orders-orders` | Finance, Fulfilment, BI | Active |
| DP-SAL-02 *(Example)* | Payments | DOM-01 | Source aligned | `payments` 1.0.0 | `corvid-payments-payments` | Finance | Draft |
| DP-FUL-01 *(Example)* | Shipments | DOM-03 | Source aligned | `shipments` 1.2.0 | `corvid-shipments-shipments` | Sales, Customer service | Active |
| DP-FUL-02 *(Example)* | Delivery performance | DOM-03 | Aggregate | `delivery_daily` 1.0.0 | `corvid-delivery-performance-daily` | Operations dashboards | Draft |
| DP-FIN-01 *(Example)* | Recognised revenue | DOM-05 | Consumer aligned | `revenue_monthly` 1.0.0 | `corvid-revenue-monthly` | Board reporting | Proposed |
| DP-[DOM]-[NN] | [Product] | [Domain] | [Source aligned / Aggregate / Consumer aligned] | [Ports] | [IDs] | [Consumers] | [Status] |

The type values follow ODPS v1.1.0 (`sourceAligned`, `aggregate`,
`consumerAligned`). Product IDs in this document are design references;
the ODPS `id` in each specification is the system identifier.

### 4.3 Product lifecycle

Every product moves through the same states. The platform records the
state in the product specification (ODPS `status`) and the catalogue
shows it to consumers.

```mermaid
stateDiagram-v2
    [*] --> Proposed
    Proposed --> Draft: Owner and consumer named
    Draft --> Active: Acceptance tests in 4.1 pass
    Active --> Active: Minor or patch version
    Active --> Deprecated: Replacement published
    Deprecated --> Retired: Sunset date reached
    Retired --> [*]
```

## 5. Self-serve data platform

<!-- Guidance: Describe the platform capabilities that let a domain team publish a product without tickets to a central team. Questions to answer: what can a domain do alone in one day, which capabilities are mandatory, how is the platform measured? Pitfall: building a platform that offers raw infrastructure only, so every domain rebuilds the same pipeline scaffolding. -->

The third principle provides shared, self-service capabilities so that
domain teams can build, publish and run products without specialist
infrastructure work. Dehghani describes the platform in planes: the
2020 article names a data infrastructure provisioning plane, a data
product developer experience plane and a data mesh supervision plane,
and the book (2022) renames them the infrastructure utilisation, data
product experience and mesh experience planes. This design groups
capabilities by the book's plane names.
Treat the platform as a product with its own roadmap
(`architecture/internal-developer-platform-charter`,
`architecture/platform-golden-path`).

| Cap ID | Capability | Plane | Self-service interface | Mandatory for products | Status |
|---|---|---|---|---|---|
| PLT-01 *(Example)* | Storage and compute provisioning per domain (Iceberg namespace, warehouse, budget) | Infrastructure | Template repository and pipeline | Yes | Live |
| PLT-02 *(Example)* | Product scaffold: dbt project, tests, CI, ODPS and ODCS files | Product experience | `create-data-product` command | Yes | Pilot |
| PLT-03 *(Example)* | Contract validation in CI against the ODCS v3.2.0 JSON schema | Product experience | CI step | Yes | Pilot |
| PLT-04 *(Example)* | Quality checks and service level monitoring with consumer-visible results | Product experience | Declared in the contract | Yes | Pilot |
| PLT-05 *(Example)* | Access policies from classification tags, masking by default | Infrastructure | Policy as code | Yes | Live |
| PLT-06 *(Example)* | Catalogue registration and search from product metadata | Mesh experience | Automatic on publish | Yes | Pilot |
| PLT-07 *(Example)* | Lineage collection with OpenLineage events | Mesh experience | Automatic from orchestrator | Yes | Planned |
| PLT-08 *(Example)* | Cost reporting per product | Mesh experience | Dashboard | No | Planned |
| PLT-[NN] | [Capability] | [Plane] | [Interface] | [Yes / No] | [Status] |

Platform service levels:

| Measure | Target *(Example)* |
|---|---|
| Time for a trained domain team to publish a new source-aligned product | 10 working days |
| Access grant through policy (no ticket) | Within 1 hour |
| Platform availability during business hours | [Target] |

## 6. Federated computational governance

<!-- Guidance: Decide which policies are global and enforced by the platform, and which are local to domains. Questions to answer: who sits on the governance group, how are policies written, tested and enforced, and how are exceptions handled? Pitfall: writing policies as documents only, so compliance depends on reviews that do not scale. -->

The fourth principle combines a federated decision body (domain
representatives, platform, security, legal and privacy) with policies
that the platform enforces automatically. Membership, decision rights
and the RACI belong in `data/data-governance-operating-model`; this
section lists the policies and how each one is enforced.

### 6.1 Global and local policies

Global policies apply to every product and are few. A policy is global
only if inconsistency between domains would break interoperability,
security or legal compliance. Everything else is local.

| Policy ID | Policy | Scope | Enforcement point | Mode | Evidence |
|---|---|---|---|---|---|
| POL-G-01 *(Example)* | Every output port has a valid ODCS v3.2.0 contract with owner and service levels | Global | CI contract validation (PLT-03) | Block publish | CI logs |
| POL-G-02 *(Example)* | Properties holding personal data carry a classification tag and are masked unless the consumer role allows | Global | Policy engine (PLT-05) | Block access | Access logs |
| POL-G-03 *(Example)* | Shared identifiers use the global formats in section 7 | Global | Contract linting | Block publish | Lint report |
| POL-G-04 *(Example)* | Breaking changes need a new major version and a deprecation notice period of at least [N] days | Global | Contract diff check | Block merge | Pull request record |
| POL-G-05 *(Example)* | Retention follows the data retention standard | Global | Table maintenance jobs | Detect and alert | Retention report |
| POL-L-01 *(Example)* | Sales freshness target for `orders` is hourly | Local (DOM-01) | Contract service level | Monitor | Service level dashboard |
| POL-[G/L]-[NN] | [Policy] | [Global / Local] | [Point] | [Block / Detect / Monitor] | [Evidence] |

Link retention and classification policies to
`data/data-retention-deletion-standard` and
`data/data-classification-policy`, and quality rules to
`data/data-quality-standard`.

### 6.2 Exceptions

| Exception ID | Policy | Product | Reason | Compensating control | Approved by | Expires |
|---|---|---|---|---|---|---|
| EXC-01 *(Example)* | POL-G-03 | DP-FIN-01 | ERP customer number cannot be changed before migration | Mapping table published with the product | Governance group, YYYY-MM-DD | YYYY-MM-DD |
| EXC-[NN] | [Policy] | [Product] | [Reason] | [Control] | [Body, date] | YYYY-MM-DD |

## 7. Interoperability standards

<!-- Guidance: Fix the few shared conventions that let products join without translation. Questions to answer: how are entities identified across domains, which time and currency conventions apply, which metadata standards are mandatory? Pitfall: leaving join keys to each domain, which forces every consumer to build its own mapping. -->

| Std ID | Area | Standard | Version | Applies to |
|---|---|---|---|---|
| STD-01 *(Example)* | Product metadata | Bitol Open Data Product Standard (ODPS) | v1.1.0 | Every product specification |
| STD-02 *(Example)* | Port contracts | Bitol Open Data Contract Standard (ODCS) | v3.2.0 | Every output port |
| STD-03 *(Example)* | Lineage events | OpenLineage | [Version] | Every pipeline run |
| STD-04 *(Example)* | Table format | Apache Iceberg | [Format version] | All table ports |
| STD-05 *(Example)* | Customer identifier | `customer_id` as issued by DOM-04, string, never reused | Internal v1 | All products with customer data |
| STD-06 *(Example)* | Timestamps | UTC, ISO 8601, with a separate local date where business days matter | Internal v1 | All products |
| STD-07 *(Example)* | Currency | ISO 4217 code with amounts in minor units | Internal v1 | All monetary properties |
| STD-[NN] | [Area] | [Standard] | [Version] | [Scope] |

Keep the glossary of business terms in `architecture/data-dictionary` or the
catalogue, and refer to it from contracts.

## 8. Logical architecture

<!-- Guidance: Show how domains, products, ports, the platform and governance connect. Questions to answer: where do products read their inputs, where do consumers read outputs, where are policies enforced? Pitfall: drawing a central pipeline with domain labels on it. -->

```mermaid
flowchart LR
    subgraph SAL["DOM-01 Sales"]
        OS["Order service"] --> DP1["DP-SAL-01 Orders"]
    end
    subgraph FUL["DOM-03 Fulfilment"]
        WS["Warehouse system"] --> DP2["DP-FUL-01 Shipments"]
        DP1 --> DP3["DP-FUL-02 Delivery performance"]
        DP2 --> DP3
    end
    subgraph FIN["DOM-05 Finance"]
        DP1 --> DP4["DP-FIN-01 Recognised revenue"]
    end
    subgraph PLAT["Self-serve data platform"]
        CI["Contract validation PLT-03"]
        POL["Policy engine PLT-05"]
        CAT["Catalogue PLT-06"]
        LIN["Lineage PLT-07"]
    end
    DP1 -.-> CI
    DP1 -.-> CAT
    DP3 -.-> LIN
    DP4 --> POL
    POL --> BI["Consumers: BI and analysts"]
```

Read the diagram as follows: each product reads its inputs through the
output ports of other products (Delivery performance reads Orders and
Shipments), never from another domain's internal tables. Dotted lines
show platform services the product uses at publish time. Consumers read
through the policy engine, which applies POL-G-02.

## 9. Operating model and teams

<!-- Guidance: Name the teams, their interaction modes and the funding model. Questions to answer: who builds products, who runs the platform, who enables domains that lack skills, and who pays? Pitfall: asking domain teams to own products without adding data engineering capacity or budget. -->

| Team | Type | Responsibilities | Interaction with others |
|---|---|---|---|
| Domain product teams *(Example)* | Stream aligned | Build and run their data products, answer consumers | Use the platform as a service |
| Data platform team *(Example)* | Platform | Build and run PLT capabilities as a product | Offer self-service; collaborate with pilot domains for the first quarter |
| Data enablement team *(Example)* | Enabling | Coach domains, run the data product owner training | Time-boxed engagement per domain |
| Governance group *(Example)* | Federated body | Agree global policies and exceptions | Meets every [two weeks]; decisions recorded |

Team types follow the vocabulary of Team Topologies (Skelton and Pais),
used by name only. Document each team's interfaces with
`architecture/team-api`.

Funding: [domain budgets fund product teams; platform funded centrally;
cost reporting per product from PLT-08].

## 10. Metrics and economics

<!-- Guidance: Choose a small set of measures that show whether the mesh delivers on the drivers in section 1.1. Questions to answer: what is the baseline, what is the target, who reports it? Pitfall: counting products published, which rewards quantity over use. -->

| Metric ID | Metric | Driver | Baseline *(Example)* | Target *(Example)* | Source |
|---|---|---|---|---|---|
| MET-01 | Median days from request to first usable product | DRV-01 | 34 | 10 | Request tracker |
| MET-02 | Share of active output ports with a valid contract | DRV-02 | 75% (18 of 24) | 100% | Contract registry |
| MET-03 | Share of active products with at least one named consumer querying in the last 30 days | DRV-01 | 83% (20 of 24) | 90% | Query logs |
| MET-04 | Incidents where consumers found a quality issue before the producer | DRV-02 | 3 per quarter | 0 to 1 per quarter | Incident log |
| MET-05 | Platform cost per active product per year | Economics | EUR 40,000 (EUR 960,000 for 24 products) | EUR 24,000 at 40 products | Finance |

*Example arithmetic:* the platform team costs EUR 960,000 a year. With
24 active products that is EUR 960,000 / 24 = EUR 40,000 per product;
at the target of 40 products it falls to EUR 24,000. The 24 products are
spread across domains as Sales 5, Catalogue 4, Fulfilment 5, Customer 4,
Finance 3 and Marketing 3. Use the same figures in every report.

## 11. Adoption roadmap

<!-- Guidance: Sequence adoption in waves with exit criteria, starting with domains that have both demand and capability. Questions to answer: which domains go first, what platform capabilities must exist before each wave, when is the central team's role reduced? Pitfall: a big-bang migration of all domains at once. -->

| Wave | Period | Domains | Platform capabilities needed | Exit criteria |
|---|---|---|---|---|
| 0 *(Example)* | YYYY-Qn | None | PLT-01, PLT-05 | Fit assessment approved, global policies POL-G-01 to POL-G-03 agreed |
| 1 *(Example)* | YYYY-Qn | DOM-01, DOM-03, DOM-05 | PLT-02 to PLT-04, PLT-06 | Five products active, MET-02 at 100% for pilot products |
| 2 *(Example)* | YYYY-Qn | DOM-02, DOM-04 | PLT-07 | MET-01 below 15 days |
| 3 *(Example)* | YYYY-Qn | DOM-06 | PLT-08 | Central team reduced to enablement and platform roles |
| [N] | [Period] | [Domains] | [Capabilities] | [Criteria] |

## 12. Risks and anti-patterns

<!-- Guidance: Record the risks specific to decentralising data and how the design mitigates them. Questions to answer: what would make the mesh fail in this organisation? Pitfall: listing generic project risks instead of mesh-specific ones. -->

| Risk ID | Risk or anti-pattern | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| RSK-01 *(Example)* | Domains publish tables without consumers or service levels | Medium | Medium | Acceptance tests in 4.1, MET-03 | [@governance-chair] |
| RSK-02 *(Example)* | Platform lags behind domain needs, domains build their own tooling | High | High | Platform roadmap reviewed with domains every quarter | [@platform-lead] |
| RSK-03 *(Example)* | Global policies grow until the governance group becomes a central bottleneck | Medium | High | Global test in 6.1; policy count reviewed yearly | [@governance-chair] |
| RSK-04 *(Example)* | Duplicate products for the same concept in two domains | Medium | Medium | Catalogue search before Proposed; ownership rules OWN-01 to OWN-03 | [@data-architect] |
| RSK-05 *(Example)* | Domain teams lack data engineering skills | High | High | Enablement team, wave sequencing, funded roles | [@cdo] |
| RSK-[NN] | [Risk] | [L] | [I] | [Mitigation] | [@owner] |

## 13. Decisions and traceability

<!-- Guidance: Record the architecture decisions and trace drivers to design elements and metrics. Questions to answer: can every driver be traced to a design choice and a measure? Pitfall: decisions made in meetings and never recorded. -->

### 13.1 Decisions

| ADR ID | Decision | Date | Status |
|---|---|---|---|
| ADR-D01 *(Example)* | Adopt ODPS v1.1.0 and ODCS v3.2.0 for product and contract metadata | YYYY-MM-DD | Accepted |
| ADR-D02 *(Example)* | Keep Marketing central until wave 3 | YYYY-MM-DD | Accepted |
| ADR-[NN] | [Decision] | YYYY-MM-DD | [Status] |

### 13.2 Traceability

| Driver | Principle | Design elements | Policies | Metrics |
|---|---|---|---|---|
| DRV-01 *(Example)* | Domain ownership, self-serve platform | Section 3.1, PLT-01, PLT-02 | POL-G-01 | MET-01, MET-03 |
| DRV-02 *(Example)* | Data as a product, federated governance | Section 4.1, PLT-03, PLT-04 | POL-G-01, POL-G-03, POL-G-04 | MET-02, MET-04 |
| DRV-03 *(Example)* | Domain ownership | OWN-01 to OWN-03 | None | MET-01 |
| [Driver] | [Principle] | [Elements] | [Policies] | [Metrics] |

## 14. Glossary and references

<!-- Guidance: Define terms readers will meet and list the sources and versions used. -->

### 14.1 Glossary

| Term | Meaning in this document |
|---|---|
| Data mesh | A socio-technical approach where business domains own and publish analytical data as products on a shared platform under federated governance |
| Domain | A business area with its own language, systems and team, usually aligned with a bounded context |
| Data product | Data plus code, metadata, contracts and service levels, owned by a domain and offered to consumers through ports |
| Output port | A versioned interface through which consumers read a product |
| Data product owner | The person accountable for a product's value, roadmap and promises |
| Self-serve data platform | Shared capabilities that let domain teams build and run products without specialist tickets |
| Federated computational governance | Governance by a group of domain and specialist representatives, with policies enforced automatically by the platform |
| Global policy | A policy that applies to every product because inconsistency would break interoperability, security or compliance |
| Source aligned, aggregate, consumer aligned | Product types by closeness to a source, combination of sources, or fit to one family of uses |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Zhamak Dehghani, "Data Mesh Principles and Logical Architecture", martinfowler.com/articles/data-mesh-principles.html | Published 3 December 2020, checked 2026-10-30 | Names of the four principles, earlier platform plane names (no text used) |
| Zhamak Dehghani, "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh", martinfowler.com/articles/data-monolith-to-mesh.html | Published 20 May 2019, checked 2026-10-30 | Names of data product qualities (no text used) |
| Zhamak Dehghani, *Data Mesh: Delivering Data-Driven Value at Scale*, O'Reilly, 2022 | Book, cited by name | Platform plane names and two added quality names (no text used) |
| Bitol Open Data Product Standard (ODPS), github.com/bitol-io/open-data-product-standard | v1.1.0, released 2026-09-08, checked 2026-10-30 | Product type values and product metadata |
| Bitol Open Data Contract Standard (ODCS), github.com/bitol-io/open-data-contract-standard | v3.2.0, released 2026-09-08, checked 2026-10-30 | Contract validation and service levels |
| Matthew Skelton and Manuel Pais, *Team Topologies* | Book, cited by name | Team type names in section 9 |
| Related templates: `data/data-product-specification`, `data/data-contract`, `data/data-governance-operating-model`, `data/data-quality-standard`, `data/data-classification-policy`, `data/data-retention-deletion-standard`, `architecture/data-dictionary`, `architecture/data-platform-architecture`, `architecture/context-map`, `architecture/team-api` | Current versions | Detail for each part of the design |

## Standard and licence note

Structure aligned with the four data mesh principles named by Zhamak
Dehghani in "Data Mesh Principles and Logical Architecture"
(martinfowler.com, 3 December 2020) and her book *Data Mesh* (O'Reilly,
2022): domain-oriented decentralized data ownership and architecture,
data as a product, self-serve data infrastructure as a platform, and
federated computational governance. The principles, quality names and
platform plane names are cited by name only; no text, figures or tables
from the article or the book are reproduced. Product and contract
metadata refer to the Bitol Open Data Product Standard v1.1.0 and Open
Data Contract Standard v3.2.0, published by the Bitol project under the
Apache License 2.0. Team type names follow *Team Topologies* by name
only. All explanatory text, tables and examples are original. Corvid
Commerce is fictional. Check the current versions of each standard
before use. Template licence: MIT.