Documentation / Practices
Data product agreements
Make ownership, quality, compatibility and use explicit.
Purpose
A contract is a versioned working agreement between the people producing, governing and consuming a product. It describes what is offered, to whom, for which purposes and with which expectations. A schema alone does not establish ownership or permission. The original KDV template is human-readable and does not claim conformance to ODCS or another technical standard.
Minimum baseline
- Identity, version, Hive, Cell and product owner
- Purpose, intended consumers and delivery interfaces
- Definitions, schema, provenance and lineage
- Classification, permitted use, retention and access conditions
- Quality thresholds, tests, freshness and incident contact
- Compatibility, deprecation period and review/approval record
Version and compatibility
Agree how to distinguish breaking changes, compatible additions and documentation corrections. Notify consumers before a breaking version replaces their agreement. Keep previous approvals and a planned transition or retirement path. Semantic versioning can be adopted, but the team must define what a change means for its consumers.
Synthetic example
A fictional service-planning team needs a weekly aggregate of requests. The service domain owns the meaning; a subdomain team prepares the data; a product owner agrees freshness and allowed use. The first release is an internal aggregate, not a copy of identifiable source records. The team records quality results and reviews whether the product supports the intended planning decision.
Review questions
- Who can decide, and is the acting role explicit?
- What rule or agreement authorises the action?
- What evidence demonstrates execution and its limitations?
- When will the outcome or exception be reviewed?
Continue reading
Original KDV Framework knowledge. Working community edition 0.1. CC BY 4.0. References retain their owners’ rights; no official assessment or certification is implied.