Before populating a DPP
- Separate common product data from category-specific legal fields.
- Connect each value to a source and accountable owner, not only to a spreadsheet cell.
- Define who can see the information: public, partner, recycler, verifier or authority.
- Control versions, effective date and the link to model, batch or individual item.
Why there is no universal mandatory dataset
The ESPR defines the Digital Product Passport framework and architecture principles. Detailed datasets are established by product group or sector legislation. A generic list can support preparation, but it cannot be treated as a complete legal requirement for every product.
The same information can also change meaning with granularity. A composition value may apply to a model or batch; a repair event applies to an individual item. Product identity and granularity therefore need to be defined before the dataset.
Main information categories
| Area | Examples to map | Control question |
|---|---|---|
| Identity | Product identifier, model, batch, serial, variant, data carrier | Does the code identify the required level precisely? |
| Operators | Manufacturer, importer, representative, facility, relevant suppliers | Are roles and identifiers current and verified? |
| Characteristics | Materials, components, substances, dimensions, performance, durability | Are definition, unit and method consistent? |
| Compliance | Declarations, certificates, test reports, standards and versions | Is the value linked to the correct evidence? |
| Impact and circularity | Footprint, recycled content, repairability, spares, disassembly, recycling | Is the method documented and applicable? |
| Use and safety | Instructions, maintenance, warnings, operating conditions | Is information available to the right role and language? |
| Lifecycle | Version, status, repairs, updates and end-of-life events | Who can change the data and how is it traced? |
| Access | Public, restricted B2B, authority and recycler data | Are access rights applied at field or document level? |
1. Identifiers and granularity
The core of a DPP is a stable identifier. Before choosing a QR code, decide what is identified: a model shared by many units, a production batch or an individual item. Product legislation may set the minimum level; the business model can add more detail where useful.
The product identifier also needs to connect to operator, facility and other identifiers required by the applicable framework. Alignment with ERP or PLM master data avoids duplicates and links the correct dataset version to the correct product.
2. Evidence, not only values
A value without provenance is fragile. For each material field, retain the source, document, laboratory or origin system, acquisition date, supplier and approver. If the value is calculated, keep the method, version, inputs and accountable person.
This allows practical questions to be answered: Was the certificate valid at production? Does it cover the right variant? Did the supplier change the formulation? Does a new test replace or supplement the previous one?
3. Data-quality rules
A DPP data dictionary should include:
- human-readable name and technical field identifier;
- definition and regulatory or business basis;
- data type, format, unit and allowed vocabulary;
- mandatory or conditional status;
- source, data owner and approver;
- associated evidence and validity period;
- access level and publication rule;
- event that triggers an update.
Automated checks can validate formats, ranges, cross-field consistency, attachments and expiry dates. Human review remains necessary where meaning depends on context or evidence quality.
4. Access rights and trade secrets
A DPP does not require every field to be public. The European framework distinguishes user groups and access rights. A consumer view may show authenticity, materials, care and repair information; a recycler may need disassembly instructions; an authority may access conformity evidence; certain commercial data remains restricted.
Classification should be applied at field and document level, not only to the entire passport. It is useful to retain the reason for an access level and the person authorised to change it.
5. Passport data and Registry data
The EU DPP Registry has been operational since 20 July 2026. It manages identifiers and metadata required for registration; the complete product dataset remains decentralised. The business data model therefore needs two coordinated outputs:
- the complete passport with role-specific views;
- the registration payload containing required identifiers and metadata.
These outputs must be reconciled so that a registration never refers to an unapproved version or an identifier that differs from the one carried by the product.
From data sheet to governed workflow
A spreadsheet can support an initial inventory, but it becomes fragile as products, suppliers and versions grow. A DPP workflow assigns tasks, sends requests, validates fields, retains evidence, manages approvals and publishes only the authorised version.
NexusDPP uses category templates and separates data contribution, review, approval and publication roles. ERP, PLM, MES, WMS and document-system integrations reduce duplication, while supplier portals collect information not available internally.
A pilot data-mapping example
- Select a representative product with a manageable supply chain.
- List 30–50 potentially relevant fields without declaring every field legally mandatory.
- Assign a source, owner, evidence and access level to each field.
- Measure completeness and the time required to obtain missing data.
- Create a test identifier, passport page and data carrier.
- Simulate a supplier change and a new version.
- Test export, API and registration in the available environment.
- Document gaps before scaling.
Official sources
- Regulation (EU) 2024/1781 — ESPRGeneral DPP requirements, access rights, identifiers and product-specific acts.
- Commission Implementing Regulation (EU) 2026/1778Operational arrangements for the EU DPP Registry.
- Commission Implementing Decision (EU) 2026/1736Harmonised standards for infrastructure and interoperability.
The examples are a working structure, not a universal legal field list. Mandatory data must be checked against the act applying to the product.