In Issue 01 I wrote that the JRC does not treat model level as sufficient on its own — it proposes model level as the baseline, adds a batch identifier among the identification data points, and pushes data that varies by production run (facility, chemical and substances-of-concern, certification and verification) down to batch level. Almost no brand’s PLM is built that way.
Europe’s retail and wholesale lobby has now spent two position papers arguing that batch level should go.
On 10 August, EuroCommerce published papers on the Digital Product Passport for apparel textiles and on the ESPR delegated act for apparel textile products. Neither got much pickup in the trade press. Both are worth your time, because together they are the clearest published map of where industry will fight the JRC — and therefore of which requirements are most likely to survive intact.
The central ask: model level, everywhere
EuroCommerce wants model-level identification as the default principle for textiles — for product identification, producer identification and product information alike. Batch-level and item-level requirements are described as disproportionate and of limited added value.
The supporting points are practical: batch definitions vary considerably between operators, which limits harmonisation, and labelling frequently happens before production parameters are finalised. The paper also notes the JRC’s own acknowledgement that item-level implementation has the lowest readiness in the textile sector, since serialisation is not common practice and would need substantial investment in marking, data management and systems integration.
It also leans on CIRPASS-2 — and this is worth checking before you repeat it. EuroCommerce says the EU-funded CIRPASS-2 project identifies model-level identification as the most operationally feasible solution for textiles. But in July, a survey of 48 members of CIRPASS-2’s own textile expert working group came out the other way, backing item-level identifiers as the long-term anchor while warning that batch-level rules remain poorly defined. Both readings are now in circulation, attributed to the same project. That tells you how unsettled this is.
What they want cut, kept and locked away
| Position | Data | Stated reason |
|---|---|---|
| Cut (broad requirements) | End-of-life information | Little evidence sorters and recyclers would use it; sorting is manual and mechanical today |
| Cut (extensive requirements) | Material information | Overlaps the Textile Labelling Regulation where that already applies; duplication |
| Cut as mandatory | Organic content | Contribution to ESPR objectives not demonstrated; percentage only if retained |
| Authorities only | Manufacturing facility detail | Commercial confidentiality; sourcing arrangements are strategic |
| Authorities only | Substance-of-concern identity, concentration, location | Not actionable for consumers; risk of misinterpretation |
| Keep, simplified | Robustness | Supported — but as a score, rating or performance class, not underlying test data |
| Keep, simplified | Recycled content | Percentage only; no absolute weight, no pre- vs post-consumer split |
Running underneath all of it is a structural argument that deserves attention on its own terms: the DPP should carry compliance information — declarations of conformity, compliance status, certificates, references to legislation and standards — and not compliance documentation — technical files, lab reports, calculation methodologies, datasets. Documentation stays with the manufacturer and goes to authorities on request, as under the New Legislative Framework and Decision No 768/2008/EC, and as under EUDR, CBAM, the Batteries Regulation, the Construction Products Regulation and PPWR.
If that argument wins, the DPP is a pointer. If it loses, the DPP is a repository, and your storage, retention and access-control problem changes shape entirely.
How to actually use this
Two errors are available here. The first is to treat a lobby filing as a forecast and design your data model to it. The second is to dismiss it as noise. Both waste the information.
What a document like this genuinely tells you is where the friction is. Requirements nobody is contesting are the ones most likely to arrive unchanged. Requirements under sustained, well-argued attack are the ones where the final text is genuinely uncertain.
That suggests three tiers of work:
Build now. Product and producer identification, recycled content as a percentage, robustness as a class or score. Contested only at the margins. You will need all of it under any plausible final text.
Design flexible. Granularity. Do not hard-code model-level into your identifier scheme because the lobby wants it — but do make sure you could carry a batch identifier without re-architecting. The cheapest insurance in this whole programme is an identifier design that can go finer later.
Don’t build yet. End-of-life data, organic content as a mandatory field, facility-level public disclosure. Genuinely contested, and expensive to collect. Track them; don’t fund them.
Operator takeaway: read section 1 of the DPP paper alongside your own identifier scheme and answer one question honestly — if the final act keeps batch-level elements, is that a configuration change or a rebuild? If it is a rebuild, that is your risk register’s top line, and it is worth money to fix while the answer is still unknown.