- CIRPASS technical source for DPP architecture and implementation concepts such as product identifiers, resolver patterns, and role-aware access; not an adopted ESPR delegated act.
"centred around the product identifier"
A tracker structure for separating adopted ESPR framework duties, adopted working-plan signals, preliminary JRC priority analysis, and future product-specific delegated acts.
Use it to assign owners and evidence without inventing final product dates, penalties, or DPP fields before the relevant delegated act is adopted.
Structured answer sets in this page tree.
Cited legal and guidance references.
ESPR is framework legislation: it enables product-specific and horizontal ecodesign rules, but the concrete requirements come later through delegated acts. This tracker keeps product-group monitoring separate from binding obligations so teams can prepare evidence and DPP dependencies without treating preliminary priority work as final law.
Start the tracker with the product groups named in Article 18 of Regulation (EU) 2024/1781 for the first ESPR working plan. Mark this source status as adopted law for prioritisation and planning, not as an adopted product-specific ecodesign obligation.
Use one row per product group and split combined entries where your portfolio needs separate owners, for example textiles, garments, footwear, furniture, and mattresses.
Use this tracker to separate adopted ESPR framework duties, preliminary priority research, delegated-act monitoring, DPP readiness, owners, evidence, and source gaps.
The tracker should not flatten all sources into one compliance status. A JRC preliminary ranking, a Commission working-plan page, a CIRPASS architecture report, and an adopted delegated act carry different weight.
Use plain status labels so reviewers can see whether a row is a watchlist item, an adopted planning signal, or an enforceable product rule.
For each product group, keep delegated-act tracking separate from DPP readiness. ESPR Article 9 says DPP information requirements apply through the applicable delegated acts; it does not itself list the final data fields for every product group.
Use expected DPP impact fields to prepare architecture and data ownership, while keeping final DPP content, data carrier, access rights, granularity, and retention fields blank until grounded in the product-specific act.
Assign ownership by tracker field, not just by regulation. Product compliance should own product-group scope and delegated-act status; sustainability should own product-aspect evidence; supply chain should own supplier data availability; IT or data architecture should own DPP system dependencies; legal should approve source-status labels.
Evidence should show both what is known and what is not yet grounded. This prevents teams from publishing a final DPP data model before the applicable delegated act specifies it.
"centred around the product identifier"
"centred around the product identifier"
"regular stakeholder consultation within the Ecodesign Forum"
"preliminary: they do not bind the Commission"
"the Commission shall prioritise the following product groups"
"the Commission shall prioritise the following product groups"
"the data to be included in the digital product passport"
"fully interoperable with other digital product passports"
"Ecodesign requirements shall be set for a specific product group"