EU Digital Product Passport Annex III data model planning

For an ESPR product group, the data model becomes operational only when the applicable delegated act defines the product group and sets its passport requirements. Article 8 requires delegated acts to specify the product group, commodity codes, ecodesign requirements, verification information format, conformity assessment module, manufacturer information, transitional period, and review date. Article 9 then adds the passport-specific decisions.

Planning teams should use Annex III as a controlled backlog: each candidate field needs a status such as required by delegated act, optional under delegated act, required by other Union law, not applicable to this product group, or unresolved pending product-specific rules. This prevents a team from building a passport shell around fields that the product-group rule has not selected.

Annex III groups passport data around product information, identifiers, compliance evidence, operator records, facility records, importer records, the responsible EU economic operator, and the backup passport service provider. The most important architecture decision is not the display label for a field; it is which identifier, source system, owner, evidence file, and access category makes the field reliable.

Each field should have a field card. The field card should name the legal source, product-group applicability, level of granularity, owner, source system, validation rule, update trigger, evidence record, access category, and whether the value must also be submitted to the registry or exposed through the web portal. Fields sourced from suppliers need provenance and approval records, not only a copied value.

ESPR requires access to DPP data to be regulated by the essential requirements and by product-group access rights in the delegated act. Article 11 lists many actors that may need access, including customers, manufacturers, importers, distributors, dealers, repairers, independent operators, refurbishers, remanufacturers, recyclers, market surveillance authorities, customs authorities, civil society organisations, trade unions, and other relevant actors.

Access planning should therefore be field-by-field. Public sustainability information, authority-only compliance evidence, supplier-sensitive composition data, repair or dismantling instructions, and update permissions should not be placed in one undifferentiated data bucket. The battery passport rules illustrate this discipline by separating public model data, legitimate-interest data, authority-only test-report data, and individual-battery data.

A DPP data model is incomplete if it only lists business attributes. Article 10 requires the passport to connect through a data carrier to a persistent unique product identifier, use open standards and interoperable formats, be machine-readable, structured, searchable where appropriate, and avoid vendor lock-in. Article 11 adds interoperability across DPPs, storage by the responsible economic operator or service provider, links between new and original passports, availability after business cessation, data authentication, reliability, integrity, security, privacy, and fraud prevention.

These technical requirements should become fields and acceptance tests. For example, an identifier cannot be approved until the team records the identifier standard or equivalent standard, carrier placement rule, resolver test, backup-provider reference, registry upload status, access-right matrix, and evidence that the displayed data matches the governed source record.

The passport data model must account for more than the customer-facing passport page. ESPR Article 13 requires a Commission registry that stores at least unique identifiers and, for products released for free circulation, the commodity code. Article 14 requires a public web portal that lets stakeholders search and compare passport data according to their access rights. Article 15 connects the registry to customs controls for products covered by delegated acts.

That means every planned field needs a channel decision. Some fields are stored only in the decentralised passport, some are submitted to the registry because the delegated act or Article 13 requires it, and some may be searchable or comparable through the web portal. The governance record should show why the field appears in each channel and how changes are synchronized.

A defensible planning pack should let a product, legal, IT, sustainability, supply-chain, and compliance reviewer understand exactly why each field exists and who can change it. The pack should be versioned by product group and delegated act because a field that is mandatory for one product group may be irrelevant or merely optional for another.

Do not publish broad claims such as a fixed EU-wide field set, a universal public-access rule, or a single implementation deadline unless the product-specific legal source supports that statement. Where the delegated act is not yet available for the product group, mark the field as a planning assumption and keep it out of binding public copy.