ESPR information requirements to DPP mapping

Grounds the rule that information requirements can require availability through a free-access website, DPP, product label, or physical means depending on the delegated act.

CEN Workshop on Digital Product Passport Guidelines

Supports treating DPP setup as a design decision covering data carriers, information portals, contents, exchanges, user interests, and operational requirements.

Section 2

Classify each data element before assigning a system owner

A practical mapping separates legal requirement text from the data element that will satisfy it. Classify each candidate item as product identity, operator or facility identity, compliance documentation, sustainability or circularity metric, lifecycle event, supplier-provided evidence, or user-facing instruction.

This classification prevents two common failures: publishing public sustainability claims without underlying evidence, and storing restricted business or authority-facing information in a consumer-facing DPP view.

Product identity: unique product identifier, product model or item reference, and the data-carrier relationship.
Actor identity: manufacturer, responsible economic operator, supplier, repairer, refurbisher, recycler, or facility information where required.
Compliance evidence: declaration of conformity, technical documentation, certificate reference, test result, or assessment record.
Sustainability data: metric value, unit, method, criteria source, benchmark reference, and conformity indicator where grounded.
Lifecycle data: repair, refurbishment, remanufacturing, end-of-life, or update events only when the product rule or architecture supports them.

Sources for this answer

Grounds DPP candidate elements including unique identifiers, compliance documentation, manufacturer and operator identifiers, facility identifiers, and back-up service-provider references.

Grounds mapping environmental information into claim-style data with criteria references, claimed values, benchmark references, conformity indicators, and evidence links.

Section 3

Map source systems and update responsibility

Each row needs an operational source of truth. The DPP is an access and exchange mechanism, not a substitute for product engineering, supplier, quality, regulatory, or lifecycle systems that create and maintain the underlying facts.

Assign both the system and the accountable owner. A value from PLM, ERP, MES, QMS, supplier portals, laboratory systems, LCA tools, or a repair/refurbishment workflow should have a named change owner, data-refresh trigger, and evidence location.

PLM or engineering owns product model, materials, component, design, and technical specification records.
ERP, MES, or manufacturing quality systems own batch, production, facility, and manufacturing-control records.
Supplier portals and procurement systems own supplier declarations, upstream materials evidence, and contractual evidence requests.
QMS, test labs, and regulatory systems own conformity assessments, declarations, certificates, standards references, and corrective-action status.
LCA, PEF, sustainability, or environmental reporting systems own calculated metrics and the calculation method trail.
Service, repair, refurbishment, and recycling systems own lifecycle updates only when the product rule and identifier granularity support those updates.

Sources for this answer

Supports separating product model, batch, and item information because information can be fixed at design time, manufacturing time, or extended over the lifespan.

Supports a decentralised architecture where DPP information may be discovered through identifiers and resolvers while data remains in responsible actor systems.

Section 4

Split public, role-based, and authority access

The mapping should include an access column for every information item. ESPR and DPP architecture sources support differentiated access: consumer-facing public data is not the same view as repairer, recycler, professional buyer, customs, or market-surveillance data.

Use simple labels in the mapping table: public, credentialed business user, value-chain role, authority, or internal-only pending review. Do not publish restricted data by default just because it appears in a DPP repository.

Public: consumer-facing information available through the web portal, label route, or default DPP consumer view.
Credentialed business user: professional-buyer, supplier, repairer, refurbisher, recycler, or remanufacturer access where role credentials are required.
Authority: market-surveillance, customs, or competent-authority access to mandatory DPP and registry information.
Restricted: confidential business information, supplier-sensitive evidence, or personal data that should not be exposed in public views.
Personal data: keep out of the DPP unless a grounded legal basis and data-protection design are established.

Sources for this answer

Grounds differentiated DPP access rights, protection of confidential business information, and the rule that customer personal data should not be stored in the DPP.

Supports using credentials and resolver-selected links so different actors receive different machine-readable data sets.

Recommended next step

Build a DPP mapping table before implementation

Use this ESPR mapping structure to connect delegated-act requirements, source systems, access decisions, identifiers, validation checks, and evidence before publishing DPP data.

Research workflow

Open Research Copilot

Answer ESPR and DPP implementation questions with cited source material.

Explore next step

Talk to Sorena

Discuss DPP implementation

Review delegated-act intake, data mapping, source evidence, and DPP architecture decisions with Sorena.

Explore next step

Section 5

Design the carrier, identifier, registry, and resolver path

For each mapped information item, record how a user or machine will find it. ESPR ties the passport to a unique product identifier and describes machine-readable data carriers such as QR codes or watermarks. CIRPASS adds an implementation pattern where a product identifier points through a resolver to the appropriate target data or view.

The row should distinguish the identifier level from the data view. A model-level identifier may support one view, while item-level lifecycle updates require a different granularity decision.

Identifier level: model, batch, or item, as defined by the delegated act or design decision.
Carrier placement: product, packaging, accompanying documentation, or online sales presentation where the applicable rule allows or requires it.
Resolver behavior: default consumer view, role-specific link types, batch access, or authority access route.
Registry dependency: unique identifier upload or registry reference where ESPR or the implementing system requires it.
Continuity: back-up provider or fallback resolver plan for insolvency, liquidation, cessation of activity, or broken original resolver.

Sources for this answer

Grounds the unique product identifier, data carrier, registry, portal, back-up copy, and ISO/IEC 15459 identifier-standard references in the ESPR framework.

Grounds the resolver pattern in which a product UID or URI routes the requester to consumer, machine-readable, role-based, or authority-facing resources.

CEN Workshop on Digital Product Passport Guidelines

Supports including data carriers, information portals, DPP contents, and information exchanges in the DPP design choices.

Section 6

Validate the mapping before publishing or registering DPP data

A defensible mapping needs validation at three levels: legal source traceability, data-quality checks, and technical exchange checks. A row is not ready until the source citation, system value, access decision, and evidence link agree with each other.

CIRPASS describes graph validation with SHACL as one way to check DPP data against templates or constraints. ETSI also emphasizes data properties such as findability, accessibility, interoperability, reusability, authenticity, integrity, verifiability, and traceability.

Legal validation: every row cites a delegated act, ESPR provision, standard, or grounded technical source.
Data validation: units, methods, value ranges, vocabulary codes, timestamps, and owner approvals are checked before exposure.
Access validation: public and restricted views are tested with consumer, business-role, and authority personas.
Resolver validation: scan or identifier resolution returns the intended consumer page, machine-readable links, and fallback behavior.
Evidence validation: conformity evidence, benchmark references, calculation records, or certificates remain reachable according to their access rules.

Sources for this answer

Supports validation of DPP knowledge graphs and describes SHACL shapes as a way to check DPP content before registration and later review.

Supports DPP data-quality properties and information-model checks for environmental sustainability and circularity data.

Section 7

Keep an evidence pack for each mapped requirement

The evidence pack should let a reviewer reconstruct why the information item exists, where its value came from, who approved it, which view exposes it, and how it was validated. Store the pack next to the mapping table rather than scattering it across source systems.

Use the pack to manage open facts. If a delegated act has not defined the product-specific DPP content yet, record that as blocked or pending rather than filling the row with invented fields.

Source extract: delegated-act or grounded-source citation, requirement text, and the interpretation decision.
Data lineage: source system, field owner, supplier input, calculation method, metric unit, and last update trigger.
Access rationale: why the item is public, role-based, authority-only, restricted, or pending.
Carrier and resolver evidence: data-carrier sample, identifier format, resolver test, registry record, and fallback plan.
Validation output: schema or SHACL result, quality review, evidence-link check, and release approval.
Change log: delegated-act updates, standard updates, DPP-system changes, source-system changes, and remediation actions.

Sources for this answer

Grounds technical documentation, declaration of conformity, and authority inspection expectations connected to delegated-act compliance.