DPP data model: product identity, fields, evidence and access rights

This page explores one part of the Digital Product Passport.

A DPP data model is more than a list of possible attributes. It defines which real-world product a record represents, where each claim originates, who approves it, how it changes over time and who may access it. Without those rules, even a polished DPP page is merely another copy of product data.

The Digital Product Passport overview explains the legal and technical system. This guide goes one level deeper and provides a product-group-neutral implementation model. It is deliberately not presented as a universal compliance template.

What is fixed today—and what remains product-specific

The ESPR establishes the system logic. DPP data must use open standards and be interoperable, machine-readable, structured, searchable and transferable. A data carrier connects the passport to a persistent unique product identifier. The applicable delegated act then determines the precise data, carrier and placement, model/batch/item granularity and access rights for a product group.

Projects can therefore prepare architecture and field contracts now, but should not market a speculative list as final EU mandatory fields. Keep three categories separate: stable horizontal requirements, evidence-based preparation and product-specific obligations that remain unresolved.

Primary sources: the ESPR, especially Articles 9–13 and Annex III, the harmonised DPP system standards and the JRC methodology for selecting DPP data.

The six layers of a robust DPP data model

1. Product identity

Identity answers the first question: which product does this passport describe? Record the identifier scheme and value, the responsible economic operator and, where required, the facility. Keep identity separate from the URL that serves data today. A stable identity must continue to resolve after a platform migration.

2. Granularity and scope

State whether the passport applies to a model, batch or individual item. Granularity determines which values may be shared and which vary by production run or serial number. A material specification may be model-level, a production date batch-level and a repair history item-level.

3. Product, circularity and compliance facts

This layer carries the claims: product properties, materials, substances, durability, repairability, recycling information, energy or environmental indicators and other product-specific data. Avoid storing finished marketing copy as the primary value. A useful field has a data type, unit where needed, definition and cardinality.

4. Evidence and provenance

A claim such as “35% recycled content” is weak without provenance. Link relevant values to a supplier declaration, test report, certificate, calculation or measurement. Evidence should record its type, issuer, issue date, validity and stable reference. A value can remain public while a commercially sensitive source document is restricted.

5. Governance and lifecycle

The model should identify the authoritative source system, field owner, approver and update trigger. Add status, version, validity period, reason for change and relationship to the previous version. A DPP is a maintained data product, not a one-off export.

6. Access and delivery

Separate stored facts from their presentation. Consumers, repairers, business partners, recyclers and market-surveillance authorities may require different views. Access rules belong in the model rather than being improvised in the front end. Trade secrets and personal data do not become public simply because they participate in an internal DPP process.

The field contract: nine properties for every important field

A field name is not enough. Document a compact contract for each relevant value:

• machine name and domain definition, independent from the current interface;

• data type and unit, such as a decimal in kilograms instead of free text;

• cardinality: required, optional or repeatable;

• granularity: model, batch or individual item;

• source system: PIM, ERP, PLM, LCA system, supplier portal or document store;

• data owner and approval role, not merely a technical contact;

• evidence rule: document, measurement, calculation or no additional evidence;

• validity and update trigger, such as expiry, supplier change, recipe change or correction;

• access and quality rule: audience, valid range, format and completeness.

These properties expose gaps before code is written. They also prevent a software vendor from quietly owning the domain logic. Keep the field model versioned and exportable outside any single DPP platform.

Choosing model, batch or item-level granularity

Do not default to serial-number level. Finer granularity increases event volume, operating cost and failure modes. It is justified where individual characteristics or lifecycle events matter. If every required fact is identical across a product family, a model passport may be sufficient—provided the product-specific act permits it.

• Model level: shared design, technical properties, operating and repair information.

• Batch level: production period, plant, material lot, test result or supplier batch.

• Item level: serial number, individual ownership or repair history and installed components.

An inherited structure is often practical: common values live at model level, while batch or item records add or override only genuine differences. This avoids millions of nearly identical records.

Mapping source systems: PIM, ERP, PLM and suppliers

The DPP platform should not become the new master for every field. A PIM commonly owns market-facing attributes and translations; an ERP owns items, batches, suppliers and transactions; a PLM owns engineering structures and bills of material. LCA or compliance systems provide calculations and assessments, while supplier portals provide primary evidence. The exact split varies, but every field needs an authoritative source and a conflict rule.

For Shopware or another commerce platform, the storefront may render or link to a DPP view, but it should not accidentally become the only archive for regulatory product data. Identity, evidence and APIs must continue to work outside a single sales channel.

Evidence instead of unsupported sustainability claims

Model evidence as its own object. One source may support several fields and one field may require several sources. Store more than a PDF URL: include issuer, method, version, validity and, where useful, a cryptographic checksum. When a correction occurs, it should remain clear which passport version relied on which evidence.

This becomes critical when DPP facts are reused for procurement, repair, market surveillance or automated decisions. Machine readability without provenance merely scales mistakes faster.

Versioning, corrections and persistent access

A printed identifier may remain in circulation for years. It should point to a controlled persistent identity, not directly to a short-lived CMS page. The delivery system may change while identity and resolution continue to work. Define whether a new version replaces, supplements or corrects a previous record.

The EU DPP Registry, available since July 2026, stores identifiers and high-level metadata rather than automatically hosting the full passport. Businesses remain responsible for the hosting, quality, access and long-term availability of their actual DPP data.

DPP JSON example: a starting structure, not a compliance template

The shortened example separates identity, facts, evidence, governance and access. It is intentionally generic. Do not copy its fields or batch granularity into a real product group without validating the applicable rules.

{
  "passport": { "status": "active", "version": 3 },
  "identity": { "granularity": "batch", "productIdentifier": {} },
  "facts": { "materials": [], "repairability": {} },
  "evidence": [{ "supports": [], "type": "supplier-declaration" }],
  "governance": { "dataOwner": "Product Compliance", "sourceSystems": [] },
  "access": { "public": [], "restricted": [] }
}

Download the versioned JSON example v1.0. A simpler visual template is also available on the DPP example and template page.

Build a DPP data model in seven steps

1. Choose a pilot product and map the likely applicable legal acts.

2. Document granularity and existing product identifiers.

3. Classify candidate fields as mandatory, strongly recommended or optional.

4. Define source, owner, meaning, format, quality and access for every field.

5. Model evidence, validity and change events.

6. Test an HTML view and machine-readable API against the same contract.

7. Validate with a real product, real data gaps and a platform-exit scenario.

The DPP implementation roadmap places this work in the wider project sequence. Where several systems, suppliers and owners must be aligned, the DPP consulting and implementation page describes a suitable delivery scope.

Common DPP data modelling mistakes

• claiming a universal mandatory-field list while product-specific rules remain open;

• treating the QR code, product identifier and product passport as the same object;

• collecting prose and PDFs without machine-readable facts and provenance;

• duplicating every value at item level when model or batch inheritance is possible;

• discussing access rights only after importing the data;

• letting one vendor own field definitions, history and identifiers;

• building a polished demo without testing correction, archiving and platform exit.

The best early test is not a perfect mock-up. Use a difficult product, a missing supplier declaration, a correction and a role change. If the model handles those cases clearly, it can support the interface later.