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

May 9, 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 May 9, 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.

Section 1

Start with product group and legal status

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 grounding sources.

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.
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 a field mandatory unless the applicable product-specific rule, ESPR Annex III, or another Union product rule supports that requirement.
Open issue: if the product-specific delegated act 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: confirm the product identifier and carrier content needed for registry or authority use before the product is placed on the market.
Customs readiness: for imported products covered by a delegated act, capture the unique registration identifier and commodity-code relation needed for customs checks when the registry and interconnection apply.

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.

Recommended next step

Turn DPP data-model intake into a publishable passport workflow

Use this workflow to 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.

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.
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.

"matched against the corresponding SHACL template"

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"

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.