Ownership records who is accountable for a data product: who signs off on changes, who to contact when something breaks, and who answers consumer questions. You assign these roles when you create a product and refine them later on the product’s Ownership panel.
A data product cannot be published to Production, or listed as trusted in the Data Market, until it has an Owner.
Ownership is accountability, not access. Assigning a role does not grant anyone the right to read the product’s data — access is governed by the data contract. The roles fall into two groups: primary roles that carry core accountability, and extended roles for domain specialists and additional contacts.
Roles at a glance
Primary roles carry core accountability; extended roles cover domain specialists and additional contacts.
| Role | Group | Multiplicity | Accountable for | When to assign | Who fits |
|---|---|---|---|---|---|
| Owner | Primary | One person | Vision, priorities, and roadmap; sign-off on go-live — a product cannot reach production without one; SLAs, KPIs, and customer-success metrics; trade-off calls between consumers and producers | Always. Every domain, data product, contract, port, and use case needs exactly one | Business/product person, not a service account or team alias. In data-mesh terms, the Data Product Owner (DPO); for a domain, the Domain Lead |
| Steward | Primary | Multiple | The data’s meaning — definitions, glossary terms, business rules; its quality — checks, freshness, completeness; policy compliance; approves data contracts before they go active | Every domain, data product, application, and data contract. Optional — recommended for anything other teams depend on, but never blocks reaching production | Business person familiar with the data’s meaning, often a Business Analyst. For a contract, the consumer-side reviewer |
| Custodian | Primary | Multiple | Runs the pipelines and operates the storage; responds to operational incidents; applies Steward-defined policies in the source system | Data products, ports, and technical assets — this is the role that genuinely varies asset by asset (e.g. one team runs the BigQuery tables, another the dashboards) | Engineer/SRE/platform team, often a team alias rather than a person |
| SME | Extended | Multiple | Surfaces edge cases, history, and business rules in design discussions; sanity-checks definitions; the person to ask before changing behaviour; for virtual assets, the mapping author | Domains and products with a longtime expert (optional); virtual assets with a clear mapping designer; use cases | Senior business analyst or longtime team member who knows the data but isn’t accountable for it — not on the workflow gate, doesn’t approve contracts |
| Producer | Extended | Multiple | Builds the product; takes the on-call rotation; the team-level alias consumers see when they ask “who runs this” | Data products only — ports, contracts, and assets don’t carry their own Producer | Members of the producing team |
Producer and Custodian often name the same people in a small organization, but the roles differ: Producer is who builds the product; Custodian is who operates the underlying storage and pipelines. In a large organization they diverge.
How ownership inherits
Roles assigned higher in the hierarchy flow down as a starting point: a domain’s Steward applies to every product in that domain until a product names its own. Inheritance is a suggestion, not a lock — assign a role locally and the local choice takes over for that object; clear it, and the object falls back to what it inherits.
This keeps accountability complete without repetitive entry: set it once at the domain level and override only where a specific product differs. Ports and technical assets sit under a product, so they inherit its accountability unless you assign a role on them directly — common for the Custodian, since different teams often run different assets.
To assign these roles in the wizard, see Step 2 — Ownership.