- Project-results source used to identify roadmap support and to avoid presenting CIRPASS roadmap candidates as adopted legal obligations.
"sector-specific DPP roadmaps"
A source-status watchlist for product groups likely to need ESPR delegated-act monitoring and DPP readiness work.
Use it to separate adopted framework rules, Commission working-plan signals, CIRPASS roadmap candidates, and gaps that still need official delegated-act text.
Structured answer sets in this page tree.
Cited legal and guidance references.
ESPR is framework legislation: product obligations become concrete through later delegated acts or horizontal measures. This watchlist helps product, sustainability, regulatory, data, and supplier teams track likely exposure without assigning invented effective dates, penalties, or final DPP fields before the product-specific acts are available.
Classify every product group by source status before assigning work. The strongest status is an adopted delegated or implementing act. The next level is a Commission working-plan or implementation page signal. A CIRPASS roadmap or JRC preparatory study is useful for readiness, but it is not a final legal obligation by itself.
For each watchlist row, keep an evidence owner who can prove the product boundary, maintain the cited source, and flag when a draft or adopted act changes the data model.
Map product groups, source status, DPP dependencies, and owner gaps before product-specific delegated acts turn roadmap signals into implementation work.
Use the watchlist as a monitoring register, not as a launch calendar. The row owner should hold product taxonomy, supplier data coverage, and current source status for each group.
Textiles and footwear need separate attention because the ESPR framework and Commission page also discuss destruction of unsold textiles and footwear, while delegated-act/DPP product requirements still need the relevant adopted product-specific text before final data fields can be asserted.
Do not build a DPP schema from a generic ESPR wish list. Build a draft register that separates product facts you can collect now from legal fields that must wait for the delegated act.
Each row should show whether the likely impact is a performance requirement, an information requirement, a DPP access or identifier requirement, a conformity-assessment evidence item, or a supplier-data dependency.
A useful watchlist is explicit about what is not yet grounded. That prevents internal teams from converting a roadmap signal into a shipment blocker or public legal claim.
Keep these fields blank or marked pending unless a grounded official source supplies the exact product-specific answer.
"sector-specific DPP roadmaps"
"inclusive planning, detailed impact assessments"
"design options"
"Digital product passports"