1. Why a Data Life Cycle?
Product data is never finished. Products, packaging components, specifications and checklists are created, approved, published, corrected, replaced and eventually withdrawn. Every system and trading partner that receives this data needs to know three things:
- which version is valid,
- from when it is valid, and
- when it stops being valid.
The Data Life Cycle (DLC) gives every managed record, which we call an item, one clear and controlled path through its digital life. The model is generic. In SyncForce Circular PIM it is applied to sales units, and the same principles apply to packaging components, proofing checklists and any other item type that needs controlled publication.
2. The Triple Life Cycle Model
The DLC is one of three life cycles that together control the go-to-market journey of a product:
| Life cycle | Journey | Managed per | Key dates |
|---|---|---|---|
| SLC: Supply Life Cycle | The physical journey | Supply chain unit / supply location | Phase In Date (PID), First Shipment Date (FSD), Phase Out Date (POD), Last Shipment Date (LSD), End of Service (EOS) |
| TLC: Trade Life Cycle | The commercial journey | Market / trade channel / customer | First Order Date (FOD), First Delivery Date (FDD), Last Order Date (LOD), Last Delivery Date (LDD) |
| DLC: Data Life Cycle | The digital journey | System / data channel | See section 5 |
The three cycles are independent. For example, a product can be fully published as data (DLC) before it can be ordered in a market (TLC), and before the first unit is shipped (SLC).
3. Items and revisions
Every item consists of two levels:
- Item: the stable identity, for example sales unit 12345. The item never changes identity and holds the overall DLC dates.
- Item revision: a numbered version of the item's data (R1, R2, R3 …). All business data lives on the revision, and each revision has its own status and dates.
Some key principles:
- An item has at most one working revision, which is the revision being prepared.
- At any moment, at most one published revision is effective, meaning its data is valid today.
- A new revision never overwrites the published one. The published revision stays valid until its successor becomes effective.
- Revision numbers are never reused, so the history of an item is always complete and traceable.
4. DLC statuses
4.1 Revision status
| Status | Meaning | Editable |
|---|---|---|
| Draft | Data is being prepared for an item that has never been published. | Yes |
| In Revision | Data is being prepared for an item that has been published before. Once an item has been published, it never returns to Draft. | Yes |
| Released | Data is complete and correct and ready for publication. It is waiting for an authorised person to publish it, or there is a business reason to wait. | No |
| Published | Data is officially published. It is effective from its Data Effective Date, which can be in the future. | No |
| Archived | Data is no longer valid. This is a final status: archived data is kept for history and can serve as the basis for a new revision. | No |
An archived revision always records why it was archived:
- Superseded: a newer revision became effective.
- Withdrawn: the item's publication ended without a successor.
- Abandoned: a released revision was never published.
4.2 How a revision moves through the statuses
| From | Possible next steps |
|---|---|
| (new item) | Draft |
| Draft | Released, Published, or deleted (only possible before the first publication) |
| In Revision | Released, Published, or discarded (the published revision stays valid) |
| Released | Published, back to Draft / In Revision for corrections, or Archived (abandoned) |
| Published | Stays Published while a new revision is prepared; becomes Archived when superseded or withdrawn |
| Archived | Final. A new revision can be created from its data (restore). |
Published data is never edited, deleted or set back to a working status. Every change goes through a new revision. This keeps every published version traceable, which matters for audits, digital product passports and regulatory compliance.
4.3 Item status
The status of the item is derived from its revisions:
- Published: it has a published revision and nothing in preparation.
- In Revision: it has a published revision and a new revision in preparation.
- Draft or Released: it has not been published yet.
- Archived: all of its revisions are archived.
5. DLC dates
5.1 Revision dates
| Abbr. | Name | Definition |
|---|---|---|
| DCD | Data Create Date | Date the revision was created. |
| LUD | Last Update Date | Date of the last change to the business data within the revision. |
| LUT | Last Update Timestamp | Technical timestamp (UTC) of the last change of any kind, including status changes. Used to synchronise connected systems. |
| RLD | Release Date | Date the revision was released for publication. |
| PBD | Publication Date | Date the revision was published. |
| DED | Data Effective Date | Date from which the published data is effective. The default is the publication date; it can be set in the future. |
| PED | Publication End Date | Date from which the revision is no longer effective: the successor's Data Effective Date, or the withdraw date. |
| ARD | Archive Date | Date the revision was archived. |
5.2 Item dates
| Abbr. | Name | Definition |
|---|---|---|
| DCD | Data Create Date | Date the item was created (the creation date of revision 1). |
| FPD | First Publication Date | Effective date of the first revision that was ever published. |
| LUD | Last Update Date | Effective date of the current revision: the date the published data last changed. |
| LPD | Last Publication Date | Date the item's publication ended. |
| ARD | Archive Date | Date the item was archived. |
| LUT | Last Update Timestamp | The latest change on the item or any of its revisions. |
5.3 Channel dates
Publication is a status in the source system. On top of that, visibility can be planned per system, data channel or user group:
| Abbr. | Name | Definition |
|---|---|---|
| FVD | First Visibility Date | First date the item is visible in a specific system, channel or user group. |
| LVD | Last Visibility Date | Last date the item is visible in that system, channel or user group. |
An item is visible in a channel only when it has an effective published revision and the date falls between its FVD and LVD for that channel.
5.4 Timeline
A revision can be published today with an effective date in the future. This lets you prepare a change, such as new packaging data from 1 January, and distribute it to all connected systems in advance. Until the effective date, the previous revision stays valid. On the effective date, the new revision takes over automatically and the previous one is archived as superseded.
7 . Exchanging DLC data
When DLC data is exchanged with other systems, for example through IMDE (Interoperable Modular Data Exchange), these principles apply:
- Only published data goes out. External partners receive Published and Archived revisions. Released data is only shared internally where it adds value, for example with an S&OP system early in the new product development process. Draft and In Revision data is never exchanged.
- Archived is exchanged too. If an archive status is never sent, archived items stay live in connected systems forever.
- Synchronise on the Last Update Timestamp. Every change, including an automatic status change on an effective date, updates the timestamp. A connected system only needs everything that changed since its last sync.
- Future effective dates are sent in advance. The receiving system switches to the new revision on its Data Effective Date.
8. Worked Example
| Date | Event | R1 | R2 | Item |
|---|---|---|---|---|
| 5 Jan | Item created | Draft | Draft | |
| 10 Jan | Released for publication | Released | Released | |
| 12 Jan | Published, effective 15 Jan | Published | Published; FPD 15 Jan | |
| 1 Mar | New revision started | Published | In Revision | In Revision |
| 18 Mar | R2 published, effective 1 Apr | Published until 1 Apr | Published (scheduled) | Published |
| 1 Apr | R2 becomes effective | Archived (superseded) | Published | Published; LUD 1 Apr |
| 1 Oct | Item withdrawn | Archived | Archived (withdrawn) | Archived; LPD 1 Oct |
9. Naming conventions
Every DLC term is one concept with several representations, depending on where it is used:
| Representation | Convention | Example | Used in |
|---|---|---|---|
| Label | Title Case | First Publication Date | Documentation and definitions |
| Abbreviation | 3 capital letters | FPD | Triple Life Cycle diagrams and timelines |
| Vocabulary term | camelCase | firstPublicationDate |
IMDE web vocabulary (imde.io/voc), linked data, Verifiable Credentials / DPP |
| Schema field | PascalCase | FirstPublicationDate |
IMDE XML and JSON exchange schemas |
| Tag label (UI) | Sentence case | First publication date | Field labels in user interfaces |
camelCase follows the linked-data convention used by schema.org (properties such as datePublished). PascalCase follows the existing convention of the IMDE exchange schemas and of XML standards such as GS1 and UN/CEFACT.
Naming map
| Label | Abbr. | Vocabulary term | Schema field | Level | Datatype |
|---|---|---|---|---|---|
| Digital Life Cycle Status | – | digitalLifeCycleStatus |
DigitalLifeCycleStatus |
Item, Revision | code |
| Archive Reason | – | archiveReason |
ArchiveReason |
Revision | code |
| Revision Number | – | revisionNumber |
RevisionNumber |
Revision | integer |
| Data Create Date | DCD | dataCreateDate |
DataCreateDate |
Item, Revision | date |
| Last Update Date | LUD | lastUpdateDate |
LastUpdateDate |
Item, Revision | date |
| Last Update Timestamp | LUT | lastUpdateTimestamp |
LastUpdateTimestamp |
Item, Revision | dateTime (UTC) |
| Release Date | RLD | releaseDate |
ReleaseDate |
Revision | date |
| Publication Date | PBD | publicationDate |
PublicationDate |
Revision | date |
| Data Effective Date | DED | dataEffectiveDate |
DataEffectiveDate |
Revision | date |
| Publication End Date | PED | publicationEndDate |
PublicationEndDate |
Revision | date |
| Archive Date | ARD | archiveDate |
ArchiveDate |
Item, Revision | date |
| First Publication Date | FPD | firstPublicationDate |
FirstPublicationDate |
Item | date |
| Last Publication Date | LPD | lastPublicationDate |
LastPublicationDate |
Item | date |
| First Visibility Date | FVD | firstVisibilityDate |
FirstVisibilityDate |
Channel / user group | date |
| Last Visibility Date | LVD | lastVisibilityDate |
LastVisibilityDate |
Channel / user group | date |
The Triple Life Cycle Model (SLC, TLC, DLC) was developed by Hans de Gier, SyncForce. © 2026 SyncForce B.V. You may share and reference this article with attribution to SyncForce.