“Built for Clear Business or Analytical Purpose”

What DPCH12 is really asserting​

DPCH12 is not asserting that:

“Someone might use this data” or “it supports analytics.”

It is asserting that:

A Data Product is intentionally designed, evolved, and governed around explicit consumer needs and business outcomes, not around source systems, pipelines, or producer convenience.

Intent is the north star of the product.

The Essence (HDIP + Data Mesh Interpretation)​

A Data Product satisfies DPCH12 if and only if:

1. There is a clear, declared purpose for the product
2. That purpose is defined in consumer and outcome terms
3. The product’s design decisions can be traced back to that intent

If the product exists “because the data is there”, DPCH12 is not met.

Positive Criteria — When DPCH12 is met​

DPCH12 is met when all of the following are true:

1. Intent is explicitly declared​

The product clearly states:

• who it is for (consumer archetypes, roles, systems, AI agents)
• why it exists (business decision, regulatory obligation, analytical insight)
• what outcome it enables (decision quality, risk reduction, efficiency)

This intent is part of the product definition, not an afterthought.

2. Product design reflects consumption needs​

Evidence includes:

• schemas shaped around consumption, not source structure
• aggregations, semantics, and freshness aligned to use cases
• output ports chosen to match consumer modes (API, query, visual)

This is where DPCH12 ties directly to DPCH10 and DPCH11.

3. Evolution is driven by consumer feedback​

Changes to the product are triggered by:

• new or evolving use cases
• consumer feedback and adoption signals
• changes in business priorities

Not by:

• upstream system changes alone
• platform migrations
• engineering refactors

Negative Criteria — When DPCH12 is not met​

DPCH12 is not met if any of the following are true:

❌ Product is source-driven​

Examples:

• “We expose everything from system X”
• “Schema mirrors the source database”
• “We publish raw extracts and let users figure it out”

This optimizes for producers, not consumers.

❌ Intent is vague or generic​

Examples:

• “For analytics”
• “For reporting”
• “For downstream use”

Such statements provide no design guidance.

❌ Consumption intent is implicit or tribal​

Examples:

• use cases exist only in people’s heads
• consumers discovered after the product was built
• product justified post-hoc

This leads to accidental, fragile reuse.

Edge Cases (Important Guidance for Agents)​

Case 1: “Single known consumer, clearly defined”​

⚠️ Partial

Rationale:

• intent exists
• but breadth of consumption unproven
• acceptable early state

Case 2: “Multiple consumers with different intents”​

✅ Met

Rationale:

• product designed to serve multiple use cases
• intent-driven abstraction validated

Case 3: “Intent exists but ignored in design”​

❌ Not met

Rationale:

• intent must shape the product, not just decorate it

Evidence Signals an Agent Should Look For​

Authoritative evidence:

• explicit product purpose statement
• named consumer personas or archetypes
• declared outcomes or KPIs

Supporting evidence:

• links to business processes or decisions
• consumption patterns mapped to CSxx archetypes
• backlog items tied to consumer needs

Red flags:

• “future use cases TBD”
• no named consumers
• design discussions focused only on sources

How an AI Agent Should Decide​

Decision rule (simplified):

If the Data Product’s structure and evolution cannot be clearly traced back to explicit consumer needs and business outcomes, DPCH12 is not met.

Why DPCH12 Is Non-Negotiable​

Without DPCH12:

• products drift into generic data dumps
• reuse becomes accidental
• cost grows without value signal
• governance cannot prioritize meaningfully

DPCH12 is what keeps productization value-driven, not platform-driven.

Canonical Statement​

DPCH12 is satisfied only when a Data Product is intentionally designed and evolved around explicit consumer needs and business outcomes, with its structure and interfaces directly traceable to declared consumption intent.

DPCH13 — Testable & Versioned

“Version-Controlled and Contract-Tested”

What DPCH13 is really asserting​

DPCH13 is not asserting that:

“The code is in Git” or “there are tests.”

It is asserting that:

A Data Product evolves through explicit versions protected by automated tests that preserve its declared intent, semantics, and contracts for consumers over time.

DPCH13 is about protecting trust during change.

The Essence (HDIP + PMDD Interpretation)​

A Data Product satisfies DPCH13 if and only if:

1. Change is intentional and visible through versioning
2. Consumer-facing contracts are explicit and tested
3. Product evolution does not silently break consumers

If consumers discover changes by surprise, DPCH13 is not met.

Positive Criteria — When DPCH13 is met​

DPCH13 is met when all of the following are true:

1. Product versions are explicit and meaningful​

The Data Product:

• has a clear version identifier (semantic or equivalent)
• distinguishes breaking vs non-breaking changes
• communicates version changes to consumers

Versions represent product meaning, not just pipeline changes.

2. Contracts are testable and enforced​

The product defines and tests:

• schema contracts (structure and types)
• semantic contracts (meaning, units, invariants)
• quality contracts (completeness, freshness thresholds)
• policy contracts (access, residency, retention)

These tests run automatically as part of product lifecycle (pre-publish, post-publish).

3. Tests protect intent and semantics​

Tests verify that:

• declared business assertions still hold
• semantic mappings remain valid
• trust signals meet minimum thresholds

This is where DPCH03 (declarative intent) becomes executable protection.

Negative Criteria — When DPCH13 is not met​

DPCH13 is not met if any of the following are true:

❌ Versioning exists only at technical level​

Examples:

• pipeline versions
• table versions without product context
• infra releases without consumer meaning

Consumers care about product behavior, not pipelines.

❌ Tests focus only on technical correctness​

Examples:

• tests validate SQL execution
• row counts without semantic meaning
• infrastructure health checks only

These do not protect consumers from semantic breakage.

❌ Breaking changes occur silently​

Examples:

• schema changes without notice
• semantics altered without version bump
• quality thresholds relaxed unnoticed

This destroys trust and reuse.

Edge Cases (Important Guidance for Agents)​

Case 1: “Schema tests exist, semantics untested”​

⚠️ Partial

Rationale:

• some protection exists
• intent still fragile
• common early stage

Case 2: “Versioned releases + contract tests”​

✅ Met

Rationale:

• consumers can rely on stability
• evolution is controlled and observable

Case 3: “Producers coordinate changes manually”​

❌ Not met

Rationale:

• manual coordination does not scale
• violates self-service and automation principles

Evidence Signals an Agent Should Look For​

Authoritative evidence:

• product version history
• automated contract test results
• pre-publish validation gates

Supporting evidence:

• changelogs linked to versions
• consumer compatibility policies
• rollback or coexistence strategies

Red flags:

• “latest” as only version
• tests owned only by engineering
• no record of breaking vs non-breaking changes

How an AI Agent Should Decide​

Decision rule (simplified):

If the Data Product can change in ways that break consumer expectations without being detected or versioned, DPCH13 is not met.

Why DPCH13 Is Non-Negotiable​

Without DPCH13:

• reuse collapses under change
• trust signals decay
• governance becomes reactive
• platform adoption stalls

DPCH13 is what makes long-lived, reliable data products possible.

Canonical Statement​

DPCH13 is satisfied only when a Data Product evolves through explicit versions protected by automated, consumer-facing contract tests that preserve intent, semantics, quality, and policy expectations over time.

DPCH14 — Economically Accountable

“Included in Chargeback / Showback Model”

What DPCH14 is really asserting​

DPCH14 is not asserting that:

“Costs are charged back” or “a billing report exists.”

It is asserting that:

A Data Product operates with full economic visibility, shared accountability, and continuous cost-to-value optimization — consistent with FinOps principles — so that it can scale sustainably as a product rather than degrade into a hidden cost center.

Chargeback is a mechanism. Economic accountability is the goal.

The Essence (HDIP + FinOps Interpretation)​

A Data Product satisfies DPCH14 if and only if:

1. Its costs, usage, and value signals are visible
2. Economic responsibility is explicitly shared between creators and consumers
3. The product is continuously optimized, not financially static

If the product’s economics are opaque or unmanaged, DPCH14 is not met, even if invoices exist.

The Three FinOps Pillars in DPCH14​

I. Visibility — The Economic Lens​

DPCH14 requires economic observability, not monetization.

The product must make visible:

• Costs

  • infrastructure
  • compute
  • storage
  • platform services

• Usage

  • who consumes the product
  • which ports are used
  • how often and at what scale

• Value signals

  • adoption
  • criticality
  • business usage context
  • (where possible) outcome proxies

This enables informed decisions without forcing artificial pricing.

II. Accountability — Shared Responsibility​

DPCH14 encodes a shared accountability model:

Producers (DPRO / Domain)​

• accountable for:

  • cost-efficient product design
  • avoiding unnecessary duplication
  • choosing appropriate freshness, granularity, and retention

• cannot externalize cost inefficiency to “the platform”

Consumers​

• accountable for:

  • responsible usage
  • avoiding wasteful or abusive access patterns
  • choosing the right product and port for their needs

Platform​

• accountable for:

  • transparent cost allocation
  • fair attribution
  • providing optimization levers

This is the heart of FinOps — not billing, but responsibility.

III. Optimization — Continuous Economic Improvement​

DPCH14 requires that economics are actively managed, not passively reported.

Evidence includes:

• regular cost-to-usage reviews

• adjustments to:

  • retention
  • refresh rates
  • aggregation levels
  • ports and delivery modes

• product lifecycle decisions informed by economics

  • invest
  • optimize
  • deprecate

A product that never revisits its economics is not mature.

Positive Criteria — When DPCH14 is met​

DPCH14 is met when all of the following are true:

1. Economic signals are visible at product level​

The Data Product exposes:

• cost attribution tied to the product identity
• usage metrics per consumer or archetype
• trend data over time

Visibility exists without needing finance mediation.

2. Economic accountability is explicit​

There is clarity on:

• who owns cost decisions
• who influences usage
• how trade-offs are evaluated

No “platform pays for everything” ambiguity.

3. Optimization is an ongoing practice​

Evidence of:

• tuning based on usage
• conscious trade-offs between quality, freshness, and cost
• decommissioning or redesign when value erodes

This is what separates products from legacy data estates.

Negative Criteria — When DPCH14 is not met​

DPCH14 is not met if any of the following are true:

❌ Costs are invisible or centralized​

Examples:

• costs absorbed entirely by central IT
• no product-level cost attribution
• domains unaware of economic impact

This destroys accountability.

❌ Chargeback exists without understanding​

Examples:

• invoices sent with no usage context
• cost allocation with no optimization levers
• financial punishment instead of learning

This breeds resistance, not maturity.

❌ Economics are static​

Examples:

• no review cadence
• no response to changing usage
• no link between value and cost

This leads to unsustainable scaling.

Edge Cases (Important Guidance for Agents)​

Case 1: “Showback only, no chargeback”​

⚠️ Partial

Rationale:

• visibility exists
• accountability emerging
• acceptable early stage

Case 2: “Chargeback without optimization”​

⚠️ Partial

Rationale:

• accountability exists
• but no learning loop
• often counterproductive

Case 3: “FinOps loop fully embedded”​

✅ Met

Rationale:

• visibility → accountability → optimization
• product economics actively managed

Evidence Signals an Agent Should Look For​

Authoritative evidence:

• FinOps dashboards per Data Product
• cost attribution tags aligned to product ID
• usage metrics by consumer and port

Supporting evidence:

• optimization actions recorded
• retention/freshness changes over time
• product lifecycle decisions informed by economics

Red flags:

• “platform cost” as a single line item
• no linkage between usage and cost
• finance-only ownership of economics

How an AI Agent Should Decide​

Decision rule (simplified):

If the Data Product’s costs, usage, and value signals are not visible, owned, and continuously optimized through shared FinOps accountability, DPCH14 is not met.

Why DPCH14 Is Non-Negotiable​

Without DPCH14:

• Data Products become invisible cost sinks
• reuse increases cost without discipline
• platform ROI cannot be demonstrated
• Data Mesh loses executive credibility

DPCH14 is what makes Data Products economically sustainable.

Canonical Statement​

DPCH14 is satisfied only when a Data Product operates with full economic visibility, shared producer–consumer accountability, and continuous FinOps-driven optimization, ensuring sustainable cost-to-value alignment over its lifecycle.