DPPData model intakeEU

EU Digital Product Passport Data-model intake workflow

A practical intake workflow for deciding which DPP fields are required, who owns the source data, how each field is verified, and whether the passport is ready to publish.

Use it before building a DPP schema, onboarding suppliers, registering identifiers, or exposing public and restricted passport data.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 24, 2026

Overview

A DPP data model should start with the product group and the legal status of the product-specific rules, not with a generic spreadsheet of sustainability attributes. This workflow turns ESPR passport requirements into intake fields for product compliance, master data, sustainability, supplier management, and DPP platform teams. The Commission Registry is operational, but its availability does not make a DPP mandatory for every product: the applicable or sector law still controls scope, fields, granularity, access, and timing.

Section 1

Start with product group and legal status

Record the product group exactly as it appears in the applicable ESPR , 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.

Product group: name the product family and product boundary, including whether the passport is expected at model, batch, or item level when a product-specific rule says so.
Responsible operator: name the economic operator placing the product on the market or putting it into service, plus the manufacturer, importer, dealer, marketplace provider, and DPP service provider where those roles apply.
Delegated-act status: identify whether the source is binding legislation, a Commission consultation or impact-assessment item, a standards document, or a project architecture recommendation.
Rule source: keep the external source URL and the specific article, annex, clause, or section that supports the field.
Intake decision: do not mark an Annex III field mandatory merely because it appears in Annex III. Mark it mandatory only when the applicable or other Union product rule selects or requires it.
Open issue: if the product-specific is not available, capture the field as proposed, preparatory, or design-ready rather than publication-ready.

Sources for this answer

Regulation (EU) 2024/1781 (ESPR)

Supports using product-specific delegated acts and ESPR Annex III as the legal gate for required passport data, identifier granularity, and passport content.

European Commission DPP impact-assessment consultation

Shows that DPP service-provider requirements and certification were still being assessed through stakeholder surveys, so intake records should label this status rather than treating it as final product data law.

Section 2

Intake fields for each DPP data element

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.

Required data category: identifier, compliance document, instruction or warning, manufacturer data, importer data, responsible EU economic operator data, facility identifier, operator identifier, commodity code, service-provider reference, or product-specific sustainability attribute.
Source owner: accountable team or party that can correct the source record, such as product compliance, manufacturer master data, importer operations, supplier quality, sustainability, customs, or the DPP service owner.
Supplier source: supplier declaration, ERP or PLM attribute, traceability system, conformity certificate, safety data sheet, test report, image bank, or certification-body record.
Access class: public consumer data, business-to-business data, authority or customs data, restricted confidential data, or service-provider backup metadata.
Quality and verification rule: accepted format, allowed vocabulary, source-system reference, update trigger, evidence artifact, and reviewer before publication.
Publication readiness: blocked, design-ready, supplier-pending, verified but restricted, ready for public DPP, or ready for registry and resolver testing.

Sources for this answer

Regulation (EU) 2024/1781 (ESPR)

Grounds the intake categories in Annex III passport elements and ESPR expectations that DPP data be accurate, complete, up to date, and accessible by stakeholder type.

CIRPASS D3.2 DPP System Architecture

Supports mapping DPP fields back to ERP, supplier, traceability, service-provider, certification, and access-level sources before publication.

Section 3

Identifier, carrier, resolver, and registry checks

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.

Identifier level: record model, batch, or item level only when supported by the applicable product-specific rule or documented design assumption.
Identifier relation: link the passport row to the unique product identifier and, where relevant, unique operator identifier, unique facility identifier, GTIN or equivalent product identifier, and commodity code.
Carrier relation: record whether the carrier is on the product, packaging, label, or another permitted location, and whether scanning resolves to the correct public DPP view.
Resolver test: confirm that the carrier resolves to stable public information and that restricted endpoints require the proper role or credential.
Registry readiness: for a product whose applicable legislation requires DPP registration, map the registration data, granularity, identifier hierarchy, commodity code where relevant, and backup-provider link before market placement or putting into service.
Registry operation: Implementing Regulation (EU) 2026/1778 sets rules for registration through the secure interface or API, automated validation, and a unique and persistent registration identifier. It was published on 17 July 2026 and enters into force on 6 August 2026.
Customs readiness: for imported products covered by a or other Union rule using this Registry, capture the unique registration identifier and commodity-code relation. Confirm the current customs-system route because automatic checks depend on the EU CSW-CERTEX interconnection.

Sources for this answer

Regulation (EU) 2024/1781 (ESPR)

Supports the identifier, data-carrier, registry, and customs-readiness checks for products covered by applicable delegated acts.

GS1 Digital Product Passport standards overview

Supports treating identification and internationally standardised data carriers as a dedicated DPP implementation workstream.

CIRPASS D3.2 DPP System Architecture

Supports the practical carrier-to-resolver-to-registry sequence used to test whether a DPP can be resolved and registered.

Commission Implementing Regulation (EU) 2026/1778

Sets rules for verified actors, registration granularity, identifier links, automated validation, commodity codes, backup links, and registration identifiers; it enters into force on 6 August 2026.

Recommended next step

Turn DPP data-model intake into a publishable passport workflow

This workflow helps connect ESPR source requirements, product data owners, supplier evidence, identifiers, carrier design, access classes, and publication gates before exposing DPP data.

Research workflow

Open Research Copilot

Answer Digital Product Passport implementation questions with cited source material.

Explore next step

Talk to Sorena

Discuss DPP data-model implementation

Review product-group scope, source evidence, identifiers, access classes, and publication readiness with Sorena.

Explore next step

Section 4

Publication gate for a DPP data model

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.

Block publication if the field has no external rule source, no source owner, or no current source-system record.
Block publication if a supplier-provided value lacks the agreed evidence artifact, such as a declaration, certificate, traceability record, or test report.
Block publication if the access class is unclear or confidential data would be exposed through the public DPP view.
Block publication if the identifier, carrier, resolver, and registry records do not point to the same product scope.
Block release if the live passport and its backup do not contain the same approved version or cannot remain available for the period set by the .
Approve publication only after validation checks pass and the update trigger is known, such as a supplier change, model change, facility change, conformity-document change, or delegated-act update.
Retain the data-model version, source URLs, rule status, reviewer, failed checks, exception rationale, and final readiness state.

Sources for this answer

Regulation (EU) 2024/1781 (ESPR)

Supports the publication gate by requiring passport data design to protect confidential business information while enabling differentiated access for stakeholders.

ETSI ES 204 082 information model for digital product information

Supports using structured environmental and circularity information models and alignment checks for DPP data rather than free-text passport fields.

CIRPASS D3.2 DPP System Architecture

Supports validation before registration by matching DPP data against a data template and assigning access controls before publication.

Primary sources

References and citations

CIRPASS D3.2 DPP System Architecture

cirpassproject.eu

Referenced sections

Supports validation before registration by matching DPP data against a data template and assigning access controls before publication.

Commission Implementing Regulation (EU) 2026/1778

eur-lex.europa.eu

Referenced sections

Sets rules for verified actors, registration granularity, identifier links, automated validation, commodity codes, backup links, and registration identifiers; it enters into force on 6 August 2026.

ETSI ES 204 082 information model for digital product information

etsi.org

Referenced sections

Supports using structured environmental and circularity information models and alignment checks for DPP data rather than free-text passport fields.

"information model to describe environmental sustainability and circularity information"

European Commission DPP impact-assessment consultation

single-market-economy.ec.europa.eu

Referenced sections

Shows that DPP service-provider requirements and certification were still being assessed through stakeholder surveys, so intake records should label this status rather than treating it as final product data law.

"future requirements for DPP service providers"

European Commission DPP Registry

single-market-economy.ec.europa.eu

Referenced sections

Official operational page for the live Registry, testing environment, and economic-operator user guide.

GS1 Digital Product Passport standards overview

gs1.org

Referenced sections

Supports treating identification and internationally standardised data carriers as a dedicated DPP implementation workstream.

"identification and data carrier as a means to access DPP data"

Regulation (EU) 2024/1781 (ESPR)

eur-lex.europa.eu

Referenced sections

Supports the publication gate by requiring passport data design to protect confidential business information while enabling differentiated access for stakeholders.