EU Digital Product Passport Data-model intake workflow

Record the product group exactly as it appears in the applicable ESPR delegated act, Batteries Regulation passport rule, Commission working-plan priority, or consultation material. A working-plan priority or standards draft is not the same as a binding product-specific DPP data model.

For each intake record, label the delegated-act status before collecting field values. Use status values such as adopted product-specific rule, draft or consultation, working-plan priority only, adjacent sector rule, or no supported rule found in the sources.

Record any exemption only from the adopted legal text. Article 9(4) allows the Commission to exempt a product group where the required DPP technical specifications are unavailable or another Union-law digital information system achieves the statutory access and authority-verification objectives. An economic operator cannot create that exemption by deciding that its ERP record, public webpage, or sector database is equivalent.

Create one intake row for each passport data element. The row should explain why the field belongs in the DPP, who can maintain it, where it comes from, who can see it, and what check proves it is ready.

Separate regulatory fields from optional or design fields. ESPR Annex III lists candidate passport elements such as compliance documentation, user instructions, manufacturer and importer information, operator and facility identifiers, commodity codes, service-provider reference, and unique product identifier.

Treat identifiers and carriers as their own intake workstream. A passport field is not publishable until the team knows the product identifier level, the carrier that exposes it, the resolver or link design, and any registry data needed by authorities or customs.

The carrier should not be chosen only for packaging convenience. ESPR ties the passport to a unique product identifier and expects the data carrier and relevant identifiers to follow recognised standards where relevant for the product.

The publication gate should stop incomplete passports before they become public claims. A DPP data element is ready only when the rule source, source owner, supplier source, access class, identifier relation, verification rule, and publication status all agree.

Keep the gate strict for public consumer data and authority-facing data. Public data should resolve cleanly from the carrier; restricted data should have a documented access class; and fields derived from suppliers or service providers should retain the source evidence that allows correction later. Before market placement, confirm that the most recent passport version also has the Article 10(4) backup copy through a DPP service provider.