ESPR digital product passport information mapping workflow

Create one inventory row for each DPP requirement in the applicable delegated act. Do not begin by copying a battery, textile, electronics, or pilot-project field list into another product group unless the legal source or a documented use case supports that field.

For each row, capture the delegated-act clause, the data element name in business language, whether the field is mandatory or optional, whether it is tied to an ecodesign information requirement or another Union-law data item, and whether the DPP is expected at model, batch, or item level.

After the legal inventory exists, map each field to the system or actor that can produce defensible data. A useful DPP map separates system-of-record data from evidence: an ERP, PIM, PLM, quality system, lab report, supplier declaration, conformity file, or service-provider backup reference may each support different fields.

CIRPASS use-case work shows why this matters: circular-economy benefits depend on solving real data gaps for repair, reuse, refurbishment, resale, sorting, and recycling, not on publishing unsupported sustainability claims. Each mapped field should therefore state the operational use case it serves and the evidence needed to validate it.

Access mapping should happen before implementation. ESPR requires delegated acts to identify which actors have access to which DPP data and who may create or update it; CIRPASS architecture guidance then shows how resolvers, typed links, credentials, and role-based or usage-control mechanisms can support differentiated access.

For each field, classify the intended audience and the reason for access. Consumers normally need a public, mobile-accessible view; market surveillance authorities need compliance verification paths; circular-economy operators may need repair, sorting, or recycling data; suppliers and DPP service providers may need controlled update or backup responsibilities.

The identifier and carrier decision is part of information mapping because it controls which product instance the data describes. ESPR requires the DPP to connect through a data carrier to a persistent unique product identifier, while Annex III lists possible identity and compliance elements such as product, operator, facility, commodity, conformity, importer, responsible-economic-operator, and service-provider references.

CEN-CENELEC guidance recommends deciding whether the DPP is at model, batch, or item level before selecting identifiers and carriers. CIRPASS architecture guidance adds that HTTP URI and DID-based approaches can both connect a tangible product to DPP data, but resolver and fallback choices affect access, interoperability, and continuity.

Close the workflow with validation rules for every mapped field. A DPP value should not be published merely because a source system contains it; the team needs a rule for freshness, completeness, source quality, evidence file, update trigger, and withdrawal or correction when the underlying product data changes.

The maintained output should be a DPP mapping register, not a static checklist. It should show each field, source, owner, access level, identifier relationship, carrier or resolver dependency, evidence record, validation status, unresolved legal or standards dependency, and next review trigger.