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 delegated act places the DPP at model, batch, or item level.

After the legal inventory exists, map each field to the system or actor that can produce and maintain the value. Separate system-of-record data from evidence: an ERP, PIM, PLM, quality system, lab report, supplier declaration, conformity file, or service-provider back-up reference may each support different fields.

CIRPASS use-case work connects DPP value to real data gaps in repair, reuse, refurbishment, resale, sorting, and recycling. Each mapped field should state the operational use case it serves and the evidence needed to validate it; an unsupported sustainability claim does neither.

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 source for access. Do not assume every consumer receives every field. The delegated act decides which actors can access which data; market surveillance and customs authorities need their specified verification paths, while repairers, refurbishers, remanufacturers, recyclers, suppliers, and DPP service providers may receive different access or update rights.

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 workshop guidance recommends settling model, batch, or item granularity before selecting identifiers and carriers. That guidance is not a binding product rule. CIRPASS describes HTTP URI and DID-based approaches that can connect a tangible product to DPP data, but the applicable delegated act and adopted technical rules control the legal implementation.

Set validation rules for every mapped field. A source-system value is not ready for publication until the organization defines its freshness, completeness, source quality, evidence file, update trigger, and withdrawal or correction rule.

Maintain a DPP mapping register showing 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.

Implementing Regulation (EU) 2026/1778 applies from 6 August 2026 to registry operations for products whose Union rule requires a DPP and registration. The responsible verified economic operator registers the passport at the required model, batch, or item level. Keep the unique registration identifier, submitted identifiers and commodity code where applicable, version timestamps, and generated proof of registration with the map. Automated semantic, identifier, and completeness checks do not prove substantive product compliance.