The Data Product Standard application helps you define, govern, and share data products and the domains they belong to. It implements open industry standards, so the products you describe in Dawiso follow established conventions and can be exported to standard formats.
Use this application when you want data products described consistently — with typed interfaces (ports), formal data contracts, quality and service-level commitments, and clear ownership — rather than as free-form catalog entries.
New to the terminology? The Glossary defines the key terms used across these pages.
What is a data product
A data product is a self-contained package of data with a clear purpose, an owner, and a defined way to consume it — more than a raw table. For the full definition and how domains organize products, see What are data products.
Completeness alone does not make a product usable. For the six characteristics that decide whether other teams adopt it, see What makes a good data product; for the failure modes to avoid, see Data product anti-patterns.
Built on open standards
The application combines three open standards, so your data products follow portable, widely adopted conventions:
- ODPS (Open Data Product Specification) — the product, commercial, and service layer.
- ODCS (Open Data Contract Standard) — the data contract, schema, and quality layer.
- Data Mesh ports — typed input, output, and management interfaces.
Together they form the Dawiso Unified Data Product Model: one model in which every field traces back to a published standard, and which exports back to ODPS and ODCS validated against each schema. Dawiso adds no proprietary layer of its own.
For what each standard contributes and how Dawiso combines them, see Built on open standards. For where each part of a product lands in ODPS and ODCS, see Standards field mapping.
The building blocks
A data product is described through several object types, grouped by purpose:
| Building block | What it describes | Learn more |
|---|---|---|
| Ports | The typed interfaces a product exposes and consumes — output, input, management | Data product ports |
| Data contracts | The formal agreement covering what a product delivers, its schema, and its terms | Data contracts |
| Quality and SLAs | Data quality checks and service-level commitments | Data quality and SLAs |
| Commercial terms | Pricing, licensing, and the organization that provides the product | Pricing, licensing, and data holders |
How data products connect
Products connect to each other through ports. One product publishes data through an output port; another product consumes it through an input port that points at that output port. This producer-to-consumer link is what Dawiso draws as data product lineage, making dependencies and impact analysis visible across teams.
For the full port model, see Data product ports. For step-by-step tasks — adding ports, attaching assets, and wiring products together — see Working with ports.
Classify data by sensitivity
Every data asset can be classified on two independent axes: how much personal information it contains, and who is allowed to see it. These classifications carry up from assets to the products built on them, so a product’s sensitivity is visible before anyone requests access. See PII Level and Confidentiality.
Create and publish a data product
To add the application to a Space and build your first product — its ports, contracts, and ownership — see The Data Product Wizard. To follow one complete product from idea to published, with concrete values at every step, see Build your first data product.
Before publishing, run through the Pre-publish checklist — it separates the rules Dawiso enforces from the ones only a reviewer will catch.
Discover products in the Data Market
Published data products appear in the Data Market, where users across the organization discover them, review their terms, and request access in a governed way. See The Data Market.
Keep a product healthy
A published product has consumers, so changing it needs care. For what counts as a breaking change and how to ship one safely, see Versioning and breaking changes. When a rule blocks a product from advancing, Troubleshooting data products lists the causes and fixes.
Object types and attributes
The model spans 30 object types, 247 attributes, 34 controlled vocabularies, and 13 governed workflow states — every field sourced from one of the standards above.
For the complete list of object types, their attributes, and how they relate, see Data product object types and attributes.
The Data Product Standard application is the standards-based counterpart to the simpler Data Product Catalog. The core ideas — domains, data products, contracts, and lineage — carry over; this application adds typed ports, structured contracts with schemas, data quality, SLAs, and commercial terms.