What it shows:
A state-machine view of how a critical piece of information (e.g., a financial record or engineering baseline) evolves over time. It maps the data’s journey from initial creation (Draft/WIP), through validation and approval (Baseline), into active consumption (Read-Only Publishing), and finally to its eventual retirement (Archived/Superseded).
Why it’s needed:
Compliance, retention policies, and capacity planning. This is used to prove to legal and compliance teams that data retention rules are understood and adhered to. It defines exactly when a piece of data becomes a legally binding “immutable record.” For the infrastructure team, it drives storage tiering strategies (e.g., moving “Sunset” data from expensive high-performance NVMe storage down to cheaper cold storage).
When to use it:
Highly recommended for SADs and HLDs when deploying any true System of Record (like an ERP, PLM, or Document Management System) or any platform governed by strict compliance and audit regulations.
When NOT to use it:
Generally best to omit for transient data systems, stateless middleware, or network infrastructure (e.g., load balancers, temporary caches, firewalls) where data packets simply pass through and are not permanently stored or version controlled.
Example:
