Skip to main content

DPCH01 — Domain-Owned

“Named Data Product Owner (DPRO) Assigned”

What DPCH01 is really asserting​

DPCH01 is not asserting that:

"A name exists in a field called data product owner."

It is asserting that:

A Data Product must be owned by the DPRO from the business domain that is accountable for defining, designing, developing, maintaining, and evolving the underlying business concept and its semantics. Ownership by technology teams or by downstream consuming domains does not satisfy this charateristic, even if those domains derive value from or heavily use the data.

The Essence (HDIP + Data Mesh Interpretation)​

A Data Product is domain-owned if and only if:

  1. The DPRO represents a business/domain mandate
  2. The DPRO’s primary accountability is business meaning, usage, and value
  3. Technology teams act as enablers, not owners

If ownership sits with technology, the product may be well engineered — but it is not a Data Product in the Data Mesh sense.

Positive Criteria — When DPCH01 is met​

DPCH01 is met when all of the following are true:

1. The DPRO role is business-aligned​

The DPRO is:

  • A domain representative (e.g. Payments, Risk, Finance, Trading)
  • Accountable for what the data means, who it is for, and why it exists
  • Empowered to make prioritization decisions based on business outcomes

Typical valid DPRO personas:

  • Product Owner (business)
  • Domain Lead
  • Business SME with mandate
  • Data Product Owner embedded in the domain

2. The Data Product roadmap is business-driven​

Evidence includes:

  • Product purpose framed in business terms
  • Evolution driven by new use cases, regulatory needs, or analytical demand
  • Success measured by business consumption, not pipeline completion

3. Technology is a supplier, not the principal​

Technology roles:

  • build, operate, and optimize the product
  • do not own its meaning or direction
  • cannot unilaterally redefine the product

Negative Criteria — When DPCH01 is not met​

DPCH01 is not met if any of the following are true, even if a “DPRO” is named:

❌ Ownership is held by a technology role​

Examples:

  • IT Application Owner (ITAO)
  • Technology Delivery Lead
  • Project / Program Manager
  • Head of Data Engineering
  • Platform team representative

Even if titled “DPRO”, this violates the principle.

❌ The product exists primarily to support a system​

Signals:

  • Product defined around source systems (“SAP Extract Product”)
  • Changes driven by schema evolution rather than business need
  • No explicit business consumers beyond IT

This is a data asset, not a Data Product.

❌ Business accountability is absent or ceremonial​

Signals:

  • Business “owner” listed but not involved in decisions
  • Roadmap controlled by IT backlog
  • Business cannot explain or defend the product’s purpose

This is proxy ownership, not domain ownership.

Edge Cases (Important Guidance for Agents)​

Case 1: “Data Product owned by Data Engineering team”​

❌ Not met

Rationale:

  • Data Engineering is a delivery capability, not a domain
  • This collapses Data Mesh back into centralized data teams

Case 2: “Business owner exists, but IT makes all decisions”​

⚠️ Partial at best

Rationale:

  • Indicates transition state

  • Can be scored as Partial only if:

    • Business mandate exists
    • Clear plan to move decision authority to the domain

Case 3: “Shared / Cross-Domain Product”​

✅ Can be met, if:

  • There is a clearly defined accountable DPRO
  • Ownership is agreed contractually across domains
  • Governance model explicitly supports federated ownership

Ambiguity is allowed; absence of accountability is not.

Evidence Signals an Agent Should Look For​

Authoritative evidence (preferred):

  • Catalog metadata showing domain ownership
  • Role definition of DPRO linked to business org
  • Product purpose statement written in business language

Supporting evidence:

  • Business backlog or roadmap
  • Named business consumers
  • Governance approval records

Red flags:

  • Owner email in IT domain
  • Product documentation written purely in technical terms
  • Roadmap tied to platform milestones only

How an AI Agent Should Decide​

Decision rule (simplified):

If the DPRO cannot credibly answer “Why does this product exist from a business point of view?”, DPCH01 is not met.

Why DPCH01 is Non-Negotiable​

DPCH01 is the load-bearing principle of Data Mesh and HDIP because:

  • Without it, decentralization collapses
  • “Product thinking” degrades into “pipeline ownership”
  • Governance becomes enforcement, not enablement
  • All other DPCHs become technical checkboxes

You can have:

  • deployability
  • APIs
  • observability
  • quality metrics

…and still not have a Data Product.

Final Canonical Statement​

DPCH01 is satisfied only when a Data Product is owned by the business domain that is the authoritative source of truth for the underlying business concept and its semantics—accountable for defining, maintaining, and evolving that meaning—rather than by technology teams or downstream consuming domains, regardless of who builds, operates, funds, or heavily uses the product.