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:
- Change is intentional and visible through versioning
- Consumer-facing contracts are explicit and tested
- 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.