---
title: "DPP data-model intake workflow for EU Digital Product Passports"
canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-data-model-intake-workflow"
source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-data-model-intake-workflow"
author: "Sorena AI"
description: "A grounded intake workflow for EU Digital Product Passport data models: product group, delegated-act status, source owner, supplier data, access class, identifiers, carrier, checks, and publication readiness."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "EU Digital Product Passport"
  - "DPP data model"
  - "ESPR product passport"
  - "unique product identifier"
  - "data carrier"
  - "access rights"
  - "product passport registry"
  - "Digital Product Passport"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# DPP data-model intake workflow for EU Digital Product Passports

A grounded intake workflow for EU Digital Product Passport data models: product group, delegated-act status, source owner, supplier data, access class, identifiers, carrier, checks, and publication readiness.

*DPP* *Data model intake* *EU*

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

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.

## 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)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - 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](https://single-market-economy.ec.europa.eu/news/take-part-our-impact-assessment-digital-product-passport-2025-07-25_en?ref=sorena.io) - 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.

## 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)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - 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](https://cirpassproject.eu/wp-content/uploads/2024/05/D32-DPP-System-Architecture.pdf?ref=sorena.io) - Supports mapping DPP fields back to ERP, supplier, traceability, service-provider, certification, and access-level sources before publication.

## 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)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Supports the identifier, data-carrier, registry, and customs-readiness checks for products covered by applicable delegated acts.
- [GS1 Digital Product Passport standards overview](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Supports treating identification and internationally standardised data carriers as a dedicated DPP implementation workstream.
- [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/05/D32-DPP-System-Architecture.pdf?ref=sorena.io) - Supports the practical carrier-to-resolver-to-registry sequence used to test whether a DPP can be resolved and registered.

*Recommended next step*

*Placement: after publication gate*

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

- [Open Research Copilot](/solutions/research-copilot.md): Answer Digital Product Passport implementation questions with cited source material.
- [Discuss DPP data-model implementation](/contact.md): Review product-group scope, source evidence, identifiers, access classes, and publication readiness with Sorena.

## 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)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - 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](https://www.etsi.org/deliver/etsi_es/204000_204099/204082/01.01.01_60/es_204082v010101p.pdf?ref=sorena.io) - 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](https://cirpassproject.eu/wp-content/uploads/2024/05/D32-DPP-System-Architecture.pdf?ref=sorena.io) - Supports validation before registration by matching DPP data against a data template and assigning access controls before publication.

## Primary sources

- [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Primary legal source for ESPR DPP requirements, including product-specific delegated acts, passport data elements, unique identifiers, data carriers, registry, access, and customs interactions.
  - Quote: "linked to a unique product identifier"
- [European Commission DPP impact-assessment consultation](https://single-market-economy.ec.europa.eu/news/take-part-our-impact-assessment-digital-product-passport-2025-07-25_en?ref=sorena.io) - Grounds the status label for future DPP service-provider requirements and certification work so the workflow does not present consultation material as final product-specific law.
  - Quote: "future requirements for DPP service providers"
- [GS1 Digital Product Passport standards overview](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Grounds the identifier and data-carrier intake checks used to connect a physical product to DPP access.
  - Quote: "identification and data carrier"
- [ETSI ES 204 082 information model for digital product information](https://www.etsi.org/deliver/etsi_es/204000_204099/204082/01.01.01_60/es_204082v010101p.pdf?ref=sorena.io) - Grounds the use of structured information models and alignment verification for sustainability and circularity data in DPP implementations.
  - Quote: "environmental sustainability and circularity information"
- [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/05/D32-DPP-System-Architecture.pdf?ref=sorena.io) - Grounds the workflow steps for assembling source data, assigning access levels, validating DPP data, resolving carriers, and registering identifiers.
  - Quote: "Data from various sources is merged"

## Related Topic Guides

- [Annex III Data Model Planning for EU Digital Product Passports](/artifacts/eu/digital-product-passport/annex-iii-data-model-planning.md): Plan EU Digital Product Passport data fields, identifiers, access rights, update owners, registry inputs, and evidence records against ESPR Annex III and product-specific delegated acts.
- [Digital Product Passport vs Digital Twin](/artifacts/eu/digital-product-passport/dpp-vs-digital-twin.md): Compare EU Digital Product Passports with digital twins: legal access duties, identifiers, public and restricted data, evidence, governance, and reuse limits.
- [Digital Product Passport vs Paper Product Passports](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): Compare EU regulated digital product passports with paper, PDF, web, and internal product passports across access, identifiers, data carriers, restricted data, customs checks, registry, and interoperability.
- [DPP customs access review workflow for ESPR products](/artifacts/eu/digital-product-passport/customs-access-review-workflow.md): Review public, restricted, and customs access for EU Digital Product Passports, including registry handoffs, portal access rights, and release-for-free-circulation evidence.
- [DPP Data Governance RACI Template for EU Digital Product Passports](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Assign accountable owners for EU Digital Product Passport data, access rights, supplier inputs, resolver links, registry uploads, verification checks, and retained evidence.
- [DPP Governance, Verification and Audit Controls](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): Build EU Digital Product Passport governance controls for data owners, supplier evidence, access logs, validation checks, audit records, and product release gates.
- [DPP QR code vs NFC data carrier choices under EU ESPR](/artifacts/eu/digital-product-passport/faq/qr-code-vs-nfc-carrier-choices.md): How to choose QR code, NFC, or another data carrier for an EU Digital Product Passport without assuming ESPR mandates one universal carrier.
- [DPP registry and web portal integration under EU ESPR](/artifacts/eu/digital-product-passport/dpp-registry-and-web-portal-integration.md): Grounded guide to EU Digital Product Passport registry and web portal integration under ESPR, covering identifiers, data carriers, access rights, service providers, and lookup design.
- [DPP vs Battery Passport: ESPR and Battery Regulation Comparison](/artifacts/eu/digital-product-passport/dpp-vs-battery-passport.md): Compare the ESPR Digital Product Passport framework with the EU Batteries Regulation battery passport by scope, timing, data, access rights, identifiers, registry, governance, and evidence.
- [DPP vs EPREL Comparison](/artifacts/eu/digital-product-passport/dpp-vs-eprel.md): Compare the EU Digital Product Passport with EPREL: product-passport scope, energy-label database role, access model, identifiers, data carriers, and overlap limits.
- [DPP vs GS1 Digital Link: Duties vs Standard](/artifacts/eu/digital-product-passport/dpp-vs-gs1-digital-link.md): Compare EU Digital Product Passport requirements with GS1 Digital Link: legal scope, identifiers, data carriers, access rights, registry, portal, customs checks, and implementation consequences.
- [EU Digital Product Passport access: public, restricted, and customs views](/artifacts/eu/digital-product-passport/public-restricted-and-customs-access.md): How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal.
- [EU Digital Product Passport API and resolver architecture](/artifacts/eu/digital-product-passport/api-and-resolver-architecture.md): Grounded DPP architecture guidance for data carriers, product identifiers, resolver lookup paths, access rights, registry integration, and interoperability without premature protocol mandates.
- [EU Digital Product Passport Applicability Test](/artifacts/eu/digital-product-passport/applicability-test.md): Check whether an ESPR delegated act or battery passport rule may require a Digital Product Passport, which operator owns it, and what evidence to keep.
- [EU Digital Product Passport architecture and integration](/artifacts/eu/digital-product-passport/architecture-and-integration.md): Grounded guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance.
- [EU Digital Product Passport checklist](/artifacts/eu/digital-product-passport/checklist.md): A concrete EU Digital Product Passport readiness checklist covering product-group scope, passport fields, identifiers, data carriers, access rights, supplier evidence, registry preparation, and publication controls.
- [EU Digital Product Passport compliance: ESPR requirements](/artifacts/eu/digital-product-passport/compliance.md): Grounded EU Digital Product Passport compliance guide covering ESPR passport data, identifiers, data carriers, access rights, registry readiness, supplier validation, and evidence.
- [EU Digital Product Passport Data Carriers, Access Control, and UX](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): How to choose DPP data carriers, identifiers, access rights, and scanning UX under ESPR Articles 9-14, with QR, NFC, RFID, registry, and customs constraints.
- [EU Digital Product Passport data requirements and fields](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): How to plan Digital Product Passport data fields under ESPR: delegated-act scope, Annex III data categories, access rights, customs data, and supplier validation.
- [EU Digital Product Passport deadlines and compliance calendar](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): Grounded EU Digital Product Passport calendar for ESPR and battery passport milestones, with product-group dates flagged as dependent on delegated acts.
- [EU Digital Product Passport FAQ](/artifacts/eu/digital-product-passport/faq.md): Direct answers on EU Digital Product Passport scope, creators, product groups, registry, customs checks, access rights, identifiers, data carriers, and governance.
- [EU Digital Product Passport identifier and data carrier design](/artifacts/eu/digital-product-passport/unique-identifier-and-data-carrier-design.md): How to design Digital Product Passport identifiers, QR or other data carriers, resolver links, registry records, access paths, and evidence without overclaiming the EU rules.
- [EU Digital Product Passport penalties and enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): What ESPR says about Digital Product Passport penalties, Member State fine rules, market surveillance, customs checks, and unresolved product-specific delegated acts.
- [EU Digital Product Passport Product Group Readiness](/artifacts/eu/digital-product-passport/product-group-readiness.md): Prepare product groups for EU Digital Product Passport rules by tracking ESPR delegated-act status, data fields, suppliers, identifiers, access rights, and registry handoffs.
- [EU Digital Product Passport requirements under ESPR](/artifacts/eu/digital-product-passport/requirements.md): source-linked overview of EU Digital Product Passport requirements under ESPR: product-specific delegated acts, data fields, identifiers, carriers, registry, access rights, supplier data validation, and open points.
- [EU Digital Product Passport supplier data validation controls](/artifacts/eu/digital-product-passport/supplier-data-validation.md): Build a supplier data validation file for EU Digital Product Passports: source owner, product link, access class, data model fit, evidence quality, approval record, and release gate.
- [EU DPP customs access: registry, portal, and restricted data](/artifacts/eu/digital-product-passport/faq/customs-access.md): FAQ on customs access under the EU Digital Product Passport: what customs can verify, how the registry and public portal differ, and how access rights limit DPP data.
- [EU DPP implementation playbook and vendor selection](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): Select Digital Product Passport vendors against ESPR requirements for identifiers, data carriers, access rights, decentralized storage, registry readiness, portal access, and verification evidence.
- [EU DPP Product-Group Readiness Checklist](/artifacts/eu/digital-product-passport/product-group-readiness-checklist.md): A source-grounded checklist for preparing a product group for an EU Digital Product Passport delegated act, covering data fields, suppliers, identifiers, carriers, access rights, and registry readiness.
- [EU DPP QR Code and Data Carrier Implementation Guide](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): Grounded guidance for using QR codes and other data carriers in EU Digital Product Passport programs, including unique identifiers, access, resolver testing, and evidence.
- [EU DPP supplier data validation workflow](/artifacts/eu/digital-product-passport/supplier-data-validation-workflow.md): A grounded workflow for checking supplier data before it is used in an EU Digital Product Passport, covering product linkage, evidence, owners, access class, and approval records.
- [EU DPP unique identifier requirements: product, operator and facility IDs](/artifacts/eu/digital-product-passport/faq/unique-identifier-requirements.md): FAQ on how ESPR Digital Product Passport identifiers connect products, economic operators, facilities, data carriers, resolvers and registry evidence.
- [Public vs restricted EU Digital Product Passport data](/artifacts/eu/digital-product-passport/faq/public-vs-restricted-passport-data.md): How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules.
- [What is a Digital Product Passport under ESPR?](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A visitor-friendly explanation of EU Digital Product Passports under ESPR: product data, identifiers, data carriers, access rights, registry, web portal, and delegated acts.
- [What is the EU Digital Product Passport registry?](/artifacts/eu/digital-product-passport/faq/dpp-registry.md): FAQ on the ESPR Digital Product Passport registry: what it stores, who uploads data, how identifiers work, and what teams should avoid assuming.
- [Which products come first for the EU Digital Product Passport?](/artifacts/eu/digital-product-passport/faq/which-products-come-first.md): FAQ on EU Digital Product Passport product priority: batteries have a separate passport rule, while ESPR product groups depend on the working plan and delegated acts.
- [Who must create an EU Digital Product Passport?](/artifacts/eu/digital-product-passport/faq/who-must-create-a-digital-product-passport.md): DPP responsibility under the EU ESPR: how manufacturers, importers, distributors, suppliers, service providers, and delegated acts fit together.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-data-model-intake-workflow