ESPR information requirements to DPP mapping

ESPR information requirements are set through product-group or horizontal delegated acts. A DPP mapping table should record the covered product group, binding requirement source, product-parameter topic, required method for making the information available, and whether the requirement points to a passport, label, free-access website, manual, or another route.

Do not treat ESPR as one universal list of final DPP fields. Article 9 requires the applicable delegated act to define the data, carrier, placement, granularity, pre-contract access, access and update actors, update arrangements, and availability period. It also permits a product-group exemption where the necessary DPP technical specifications are unavailable or another Union-law system achieves the stated access and compliance-verification objectives.

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.

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. Product lifecycle management (PLM), enterprise resource planning (ERP), manufacturing execution (MES), quality management (QMS), supplier portals, laboratory systems, life-cycle assessment (LCA) tools and repair workflows may hold different values. Give each value a named change owner, data-refresh trigger and evidence location.

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.

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. For regulated implementation, the delegated act controls whether the DPP is at model, batch, or item level. A pilot may test another granularity, but the map must label it as a design assumption rather than a legal requirement.

Commission Implementing Regulation (EU) 2026/1778 enters into force on 6 August 2026 and sets the DPP registry process. Where the applicable Union rule requires both a passport and registry registration, a verified economic operator registers it at the required granularity. The registry returns a unique registration identifier and supports version timestamps and downloadable proof of registration. The proof remains available for 90 calendar days and can be regenerated, but neither it nor the registry's automated checks establishes substantive product compliance.

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 Shapes Constraint Language (SHACL) as one way to validate graph data, which represents information as linked elements and relationships. A SHACL template defines required elements, relationships and value constraints, then reports failures when the passport data does not match. ETSI also identifies findability, accessibility, interoperability, reusability, authenticity, integrity, verifiability and traceability as useful data properties.

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.

Before production use, confirm the adopted delegated act, current DPP technical specifications, applicable identifier standards, registry and customs arrangements, data-protection basis, and every actor's contractual and legal authority to create or update data.

The applicable legal provisions and delegated act control the regulated fields and access rights. ETSI, CEN workshop material and CIRPASS architecture outputs provide information-model, resolver, access and validation patterns that need to be checked against those requirements.