A digital product passport starts with a data-design question: which facts belong to the product model, which belong to a production batch, and which belong to one physical item?
Putting everything in one editable product description makes an early demo easy. It makes later corrections, supplier changes and individual service histories harder to manage. Separate identity, evidence and presentation before scaling the number of passports.
Begin with the applicable product rules
The EU Ecodesign for Sustainable Products Regulation, or ESPR, leaves key passport details to product-specific delegated acts. Article 9 links the information's model, batch or item level to the applicable act; Article 11 addresses access and update rights. See Regulation (EU) 2024/1781.
The structure below is a planning pattern, not a universal mandatory field list. Confirm the required information, carrier, access rules and retention period for the product you place on the relevant market. For the wider preparation process, see the DPP readiness checklist.
Give each fact a home
| Level | Illustrative data | Why the distinction helps |
|---|---|---|
| Model | Product family, repair instructions, standard specifications | Shared information can be maintained consistently |
| Batch | Production lot, supplier evidence, manufacturing date | A supplier change can be tied to the affected production |
| Item | Serial identity, individual repair or replacement events | One item's history does not alter every other passport |
These are examples, not assertions that every field is required at that level. A characteristic that normally belongs to the model may need a batch-specific version when production changes.
Consider a hypothetical jacket line. The general care guide belongs to the model. Evidence for a particular fabric delivery belongs to the relevant batches. A repair to one jacket belongs to that item. Replacing the care guide should not silently rewrite which fabric evidence supported an earlier batch.
Keep identifiers separate from destinations
Your internal SKU, a GTIN, a batch code, a serial number and an NFC chip identifier serve different purposes. Define the mappings explicitly and decide which system owns each one.
GS1 Digital Link supports product identifiers and qualifiers such as batch and serial information. Its quick-start guide explains how they are represented in a web address. An identifier should remain stable even if the website displaying the record changes.
Plan domain ownership, redirects and exports before printing permanent packaging. Changing a page design should not require relabelling products already in circulation.
Create a field register with owners
For every proposed field, record:
- A precise definition and unit, where relevant.
- The level at which it applies: model, batch or item.
- The source system or supporting document.
- The person or team responsible for approval.
- The audiences allowed to see or change it.
- The event that requires a review or update.
Avoid a single “sustainability” text box containing unqualified claims. A structured value with an identified methodology and supporting evidence is easier to review than a paragraph copied from a supplier brochure. If a value is unknown, record that state rather than filling the field with a guess.
Design public and restricted views
A consumer may need instructions and repair information. A service partner may need operational details that should not appear on the public page. Decide access at the field or resource level, then test each role using real accounts.
Keep customer and order data out of public product URLs. Linking a service case internally does not require publishing the customer's identity. Product data, customer records and access credentials should have distinct boundaries in the design.
Version changes and preserve evidence
Agree how a correction differs from a new lifecycle event. Store who made the change, when it became effective and the evidence used to approve it. A new supplier document should not erase the previous document's relationship to products already produced.
Test an export and a restoration exercise during the pilot. Ask whether another team could reconstruct the record, understand its identifiers and locate the supporting documents without the original implementer. This is an operational test, not an automatic claim of interoperability or legal compliance.
Hashentic offers configurable product records and verification workflows. Explore the DPP platform and the broader platform capabilities. Bring a small sample of real product and supplier data to a demo discussion; mapping a few complete records is more useful than starting with an empty template containing hundreds of fields.
