Every data product moves through a defined lifecycle: eight states from first idea to retirement. The current state tells consumers how far they can rely on the product — an idea in Announcement is not something to build on, while a product in Production is live and safe to depend on.
The eight states are the same values as the status field in the Open Data Product Specification, so a product’s lifecycle position is portable and means the same thing to any tool that supports the standard. To create a product and move it through these states, use The Data Product Wizard.
The eight states at a glance
| State | What it means | Safe to depend on? |
|---|---|---|
| Announcement | An announced concept; nothing is built yet | No — it is only an idea |
| Draft | Committed and being specified; construction not started | No |
| Development | Being built — pipelines, schemas, and assets | No |
| Testing | Running in a non-production environment for QA | No — still under test |
| Acceptance | Business sign-off (UAT); governance artefacts locked in | Not yet — in final review |
| Production | Live | Yes — safe to build on |
| Sunset | Deprecation announced; still honoring its SLAs | Only if you already depend on it, and migrate off |
| Retired | Switched off; data no longer served | No — withdrawn |
How a product moves between states
A product advances one state at a time. For rework, it can also step back one state — Testing returns to Development, and Acceptance returns to Testing — so a defect found late does not force a restart.
Two gates are enforced and block the move until they pass:
- Leaving Draft: the product must have at least one output port.
- Leaving Acceptance: every input port must be wired to an upstream product’s output port.
One rule protects the go-live decision:
- The product must have an Owner before it can enter Production or Sunset. Every other role — Steward, Custodian, SME, and Producer — is optional and never blocks the move. See Ownership for what each role means.
Production is a one-way move. Once a product is live it advances only to Sunset and then Retired — it cannot return to Development or Testing. Retired is terminal; to bring a retired product back, clone it into a new product.
The states in detail
1. Announcement
The product is an announced concept — nothing is built yet, so this is the cheapest time to change direction. You draft a working name and a short purpose statement, pick a tentative domain (the business area it belongs to), write a first-pass description of what it is, why it exists, and who it is for, and share it to collect early feedback.
To advance, give the product a name, a domain, and a first description. None of these block the move to Draft — they are recommendations.
2. Draft
The product is committed and being specified, but construction has not started. You fill the identity fields — product ID, type, visibility, and governance profile — add the value proposition, tags, and categories, and define at least one output port.
To advance, the product must have at least one output port. Without one it has nothing to deliver and nothing to build toward, so this gate is enforced.
3. Development
The product is being built: pipelines, schemas, and data assets are created. Output ports get their assets attached, input ports are wired to upstream products, the data contract is filled out, and quality checks and SLA targets are defined.
To advance, it helps to have assets attached to a port, a draft contract, and at least one quality check. These are recommended — Testing goes more smoothly with them — but none block the move.
4. Testing
The product runs in a non-production environment so its correctness can be verified. Quality checks are run, contract compliance is validated against real data, and use cases are exercised end to end. A defect found here sends the product back to Development.
To advance, document at least one use case. Advancing is a human sign-off that QA ran cleanly, not an automatic check.
5. Acceptance
The business confirms the product meets the need. The final governance artefacts — pricing, license, and the data holder, plus the team and support channels — are locked in, and the contract is signed.
To advance, every input port must be wired to an upstream source; a product with no input ports passes automatically. The product must also have an Owner before it can enter Production.
6. Production
The product is live and consumers depend on it. The work is now operational: upholding the SLA, monitoring quality, handling access requests, and bumping the version with clear notes for every change shipped.
To advance, moving to Sunset is a deliberate business decision made by an Owner or Steward — typically when a replacement is live or the source is going away. It is one-way: a live product cannot return to an earlier state.
7. Sunset
A planned end-of-life is announced, but the product still honors its SLAs. No new consumers are added; existing ones are helped to migrate, the replacement or migration path is documented, and the final snapshot is archived. If the deprecation is cancelled, the product can return to Production.
To advance, retirement is a manual decision once all consumers have migrated off.
8. Retired
The product is switched off and no longer serves data. Its record is kept so downstream lineage still resolves and shows an “upstream-retired” advisory to anyone still pointing at it. Deleting the record would break that signal.
This is a terminal state — there is no further transition. To bring a retired product back, clone it into a new product.
Changing a product that is already live
Advancing through the states is only half of a product’s life; the other half is changing it while consumers depend on it. A product in production can gain fields, ports, and versions without moving state at all. For what counts as a breaking change and how to ship one, see Versioning and breaking changes.
The data contract has its own lifecycle
A data product’s lifecycle is separate from its data contract’s. A contract runs a shorter five-state cycle — proposed, draft, active, deprecated, and retired — so a contract can be revised and re-approved without moving the product through its own states. See Data contracts for that lifecycle in full.
Grounded in the Open Data Product Specification
The eight states are the values of the status field defined by the Open Data Product Specification (ODPS), published at opendataproducts.org. Because Dawiso uses the standard’s states directly, a product’s lifecycle position exports cleanly and carries the same meaning in any tool that supports ODPS. For how Dawiso combines ODPS with the other standards, see Built on open standards.