Publishing a data product makes it visible to the organization and invites other teams to depend on it. This checklist is what to verify before that point.
Two kinds of item appear below. Enforced items are checked by Dawiso — you cannot publish without them. Quality items are not blocked by anything, and they are the ones that decide whether the product is actually adopted. A product can satisfy every enforced rule and still be one nobody trusts.
Identity
| Check | Kind | Why |
|---|---|---|
| The product belongs to the correct domain | Enforced | The domain sets the business area and the governance context |
| Name describes the product, not its storage location | Quality | Customer churn signals beats churn_scores_daily |
| Product ID follows your portfolio convention and is final | Enforced | Other systems reference it; changing it later breaks them |
| Type and visibility are set deliberately | Enforced | Visibility decides who can see the product at all |
| Description explains the product to someone who has never seen it | Quality | This is the first thing a consumer reads |
| Value proposition states a benefit, not the contents | Quality | Answers “why should I use this”, which drives adoption |
Accountability
| Check | Kind | Why |
|---|---|---|
| Owner is a named person, not a service account or alias | Quality | Every question about the product needs a destination |
| Steward is assigned for meaning and quality | Quality | Owns definitions and approves the contract |
| Custodian is assigned for the pipelines | Quality | Named operator when a refresh fails |
| The Owner knows they own it | Quality | The wizard pre-fills you as Owner; an unaware owner is no owner |
A production product with no accountable person is the most common reason a catalog stops being trusted. See Ownership.
Interfaces
| Check | Kind | Why |
|---|---|---|
| At least one output port exists | Enforced | A product with nothing to deliver cannot leave draft |
| Every output port has at least one asset | Enforced | An empty port publishes nothing |
| All assets in a port share one technology | Enforced | Keeps the delivery format, contract, and access model consistent |
| Every input port is wired to an upstream source | Enforced | An unwired input is an unfinished dependency |
| Ports are named for what they deliver | Quality | Consumers pick a port by its name |
| Ports are split by audience, not by convenience | Quality | Narrow dependencies are easier to keep stable |
Governance
| Check | Kind | Why |
|---|---|---|
| A data contract covers each port other teams consume | Quality | Without one, no agreed schema and no stated terms |
| The contract’s schema matches what the port actually delivers | Quality | A wrong schema is worse than none — it misleads |
| The Steward has approved the contract | Quality | Confirms the promise meets consumer needs |
| Pricing, license, and data holder are set if the product is shared externally | Quality | Consumers need to know the terms of use |
Contracts are optional by design, which supports starting small. The trigger for adding one is a consumer outside your team. See Data contracts.
Quality and service levels
| Check | Kind | Why |
|---|---|---|
| Freshness and availability reflect what the pipeline delivers today | Quality | Promising more than you deliver breaks trust once |
| At least one quality check exists on the data | Quality | Evidence the data is tested, not just described |
| Someone is alerted when a check fails | Quality | An unwatched check provides no assurance |
Classification
| Check | Kind | Why |
|---|---|---|
| PII Level is set on the underlying assets | Quality | Blank reads as unknown, not as “no personal data” |
| Confidentiality is set on the underlying assets | Quality | Tells reviewers and consumers how to handle the data |
| The rolled-up classification on the product looks right | Quality | One sensitive column raises the whole product |
Classify at the column or table level and let the values roll up. See PII Level and Confidentiality.
Before you click publish
Three final questions catch most of what the tables above miss:
- Could someone from another team use this product without messaging you? If not, the gap is usually the description, the contract schema, or field-level documentation.
- Are the SLA numbers ones you would defend in three months, on a bad week?
- If this product disappeared tomorrow, would anyone notice? A product nobody needs is worth retiring rather than publishing.
For the reasoning behind these checks, see What makes a good data product. For the failure modes they prevent, see Data product anti-patterns.