| name | data-product-design |
| description | Designs governed, domain-owned, discoverable and reusable data products. Use when packaging datasets as products, defining ownership, or reviewing product readiness. |
Data Product Design
When to use
Use for reusable datasets, APIs, event streams, analytical products or source-to-refined outputs.
Objective
Produce a practical, concise, traceable architecture artefact that a coding agent can use to guide implementation or review.
Procedure
- Identify consumers and decisions.
- Define purpose, scope and non-goals.
- Assign owner and steward.
- Define interface and contract.
- Define quality SLOs.
- Define metadata, classification, lineage and access.
- Define lifecycle, support and deprecation.
- Define adoption/value metrics.
Required outputs
- Purpose and consumers
- Owner/steward
- Interface and contract
- Quality SLOs
- Classification/access model
- Lineage and support model
Best-practice alignment
Apply DAMA-DMBOK2-style separation of data governance, architecture, modelling, security, integration/interoperability, master/reference data, metadata and quality. For cloud/shared data, apply CDMC-style expectations: ownership, classification, entitlement/access evidence, lineage/provenance, lifecycle/retention, quality controls and auditable evidence.
Quality checks
- Accountable owner exists.
- Consumers/use are clear.
- Quality and metadata are defined.
- Access and lineage controls exist.
Avoid
Do not call a dataset a product without ownership, consumers and operating expectations.
References
Verification
