Digital Product Passport Data Model: Identity, Versions and Evidence

A Digital Product Passport data model needs a stable identity and a controlled history of change. A QR code, web page or export file is only a surface. The model behind it must show which product is described, which version was effective, where values came from, who may access them and what was published.

The applicable data fields depend on the product group and the relevant legal acts. The European Commission’s ecodesign and sustainable products information is a useful primary source for the framework; it does not turn this article into a universal legal field list.

Keep identity separate from versions

Choose an identity granularity deliberately: model, configuration, batch or individual item. The identity should remain stable while descriptive or regulatory data changes. A new material declaration should not create a new physical product identity; it should create a new governed version or event according to the organisation’s rules.

At minimum, distinguish a stable product key, manufacturer or responsible actor, product family, market role, and the identifiers used by connected systems. Do not confuse a globally recognised identifier with regulatory responsibility. The identifier helps systems refer to an object; the applicable law determines duties.

Treat a passport version as a snapshot

A published version is the set of values and evidence that was approved for a defined point in time. Store effective time, publication time, source references, validation result and the actor or process that approved publication. Corrections should preserve the prior snapshot and produce a traceable successor where the workflow requires it.

Keep operational values separate from the publication snapshot. An ERP quantity may be edited for a business reason; a published passport must retain the value and evidence state that readers were shown. This separation makes rollback and audit reconstruction possible without pretending the operational system is immutable.

Model provenance and access with the value

A field without provenance is hard to defend. Store the source system or document, source revision, received time and transformation history for important claims. Access classification belongs in the model as well: some values may be public, some available to business partners and some reserved for authorities or internal reviewers. A public projection should be generated from the governed record rather than assembled by hand.

Design for conditional profiles

Avoid a single giant table of every possible field. Start with a stable core—identity, responsible actors, version, lifecycle state, provenance and access—and attach versioned product or regulatory profiles. Profiles can define required fields, units, controlled vocabularies and evidence relationships without changing the identity model.

This supports incremental rollout. A team can pilot one product group, learn where supplier data is weak and add another profile without rewriting historical passport snapshots. It also prevents a future rule from silently changing the meaning of an older publication.

Publication and retrieval are part of the model

Publishing needs stable addresses, machine-readable output, accessibility, authentication or authorisation boundaries where needed, and a record of what was exposed. Retrieval should resolve the intended identity and version, then apply the viewer’s access rights. It should not return whichever current row happens to match a product name.

The Digital Product Passport overview places this identity model alongside the broader product and evidence architecture. A good model lets a reviewer answer: which product was this, which version was shown, which evidence supported it, and who could see it?

For implementation planning, test identity collisions, duplicate imports, version publication, corrected evidence and access changes before connecting every source system. The model is ready when change is explicit and history remains readable.