Product type
Reusable classification and industry context
Product-data architecture guide
Digital Product Passport Data Model Design for Manufacturers
Structure product identity, regulated fields, evidence and lifecycle history so every published passport remains accurate, traceable and adaptable.
Model, batch and itemStructured fieldsEvidence and eventsImmutable versions
Start with structure
A DPP is a connected information system, not a flat spreadsheet
A useful data model explains which product a value belongs to, what the value means, who owns it, where it came from, who may see it and how it changes over time. A long table of fields cannot reliably answer those questions.
The architecture should separate reusable definitions, physical product identity, published passport versions, evidence and lifecycle events while keeping their relationships explicit and queryable.
Reference hierarchy
Connect reusable product definition to the correct physical scope
Product definition
Governed structure shared by a product family
Product master
Commercial or engineering model and its approved attributes
Batch or serialised asset
Physical production scope or unique item identity
Passport instance
Published view bound to the correct level, template version and evidence
Do not force item-level history into model-level fields
Shared specifications can be inherited from the product master, while manufacture, inspection, repair and status data remain attached to the batch or individual asset where they occurred.
Field-level governance
Build a data dictionary before building the passport screen
Every field should carry enough metadata to support validation, interoperability, ownership and change. The visible label is only one part of the definition.
| Definition element | What it controls |
|---|---|
| Meaning | A precise business definition, not only a database column name |
| Data type and format | Text, number, date, boolean, identifier, controlled vocabulary or structured object |
| Unit and vocabulary | Permitted units, code lists, language and semantic reference |
| Requirement rule | Required, optional or conditional—and the condition that activates it |
| Ownership and source | Accountable function and authoritative ERP, PLM, supplier or other source |
| Validation | Range, pattern, dependency, evidence and approval checks |
| Access class | Public, authenticated, auditor or authority, internal or restricted |
| Time and version | Effective date, update trigger and behaviour after publication |
Linked records
Keep identity, evidence, events and access connected—but distinct
Identifiers
Keep product, operator, facility and carrier identifiers as governed objects. A QR or NFC carrier resolves the identity; it is not the passport data model itself.
Evidence
Manage documents and immutable versions separately, then link the correct evidence version to the product, asset, passport or lifecycle context.
Lifecycle events
Record inspections, repairs, transfers and status changes as append-only events. Correct mistakes through traceable superseding events.
Access policy
Apply visibility and permissions at the appropriate field, evidence and event boundary rather than cloning inconsistent passports for each audience.
Version architecture
Separate definition changes from historical passport truth
A passport template can evolve as requirements or business needs change. Once a template version is published and used, historical passports should remain bound to that immutable version.
New passports can use the latest approved version. Existing published content should change through governed versioning, while event corrections retain both the original and superseding record.
Two controlled timelines
Definition timeline
Draft → reviewed → published template versions
Passport timeline
Draft → approved → published → superseded or revoked
Event timeline
Original append-only event → optional superseding correction
Interoperability
Model for meaning before mapping the API
Open exchange depends on consistent semantics, identifiers, units, vocabularies and relationships. An API can move data, but it cannot repair an ambiguous field model.
Keep internal records mapped to the applicable legal dataset and published technical standards. This allows the exchange format to evolve without rebuilding product history.
- Give every governed object a stable internal identity independent of its display name
- Separate reusable definitions from product records and published passport instances
- Represent model, batch and item levels explicitly instead of hiding them in free text
- Store identifiers separately from carrier technology so QR and NFC can resolve the same product
- Bind published passports to immutable template and evidence versions
- Preserve source, owner, validation and access metadata for every regulated field
- Append lifecycle history and corrections rather than overwriting accountable events
- Expose open, structured outputs without making the presentation layer the system of record
Implementation route
Eight steps from product family to governed passport model
Choose one product family
Use a representative product with real source data, evidence and lifecycle behaviour.
Confirm passport level
Prepare model, batch and item relationships; apply the level required by the applicable product rule.
Create the data dictionary
Define meaning, format, ownership, source, validation, access and update behaviour.
Map identities
Connect product, operator, facility, batch, item and carrier identifiers without fragile name matching.
Model evidence and events
Link immutable evidence versions and append-only lifecycle records to the correct target.
Version the passport definition
Publish an approved template version and keep historical passports bound to it.
Validate and publish
Check required fields, relationships, evidence and permissions before creating the published view.
Exercise change
Test a correction, new product revision, evidence update and lifecycle event before scaling.
UniQorn Trace™ data foundation
Prove the model with one real product family
UniQorn Trace separates product definitions, product masters, serialised assets, identifiers, passport-template versions, evidence and lifecycle events. The configurable structure can be adapted when product-specific requirements are confirmed.
Common questions
Digital Product Passport data-model FAQ
What is a Digital Product Passport data model?
It is the governed structure that connects product hierarchy, identifiers, fields, evidence, access rules, versions and lifecycle events. It defines what each value means and how records relate—not merely how a passport page looks.
Is there one universal DPP dataset for every product?
No. ESPR establishes the system requirements, while applicable product-specific delegated acts define the required data and whether the passport is created at model, batch or item level.
What is the difference between a product template and a passport template?
A product template defines the governed attributes used to describe a product family. A passport template defines which approved product data and evidence are published, organised and accessed for a particular passport use and version.
Should model, batch and item data be stored in one table?
They may share technical infrastructure, but their identities and relationships should remain explicit. Model data can be inherited while batch and item records hold information that applies only to that production scope or physical asset.
How should DPP corrections be modelled?
Do not silently rewrite published history. Create a governed new passport version for changed published content or append a superseding lifecycle event that retains the original record and correction relationship.
Can a DPP data model connect to ERP and PLM?
Yes. The model should preserve authoritative ownership and map source-system records through stable identifiers, validation and transformation rules. The DPP layer should not become an uncontrolled duplicate of every enterprise system.
Primary sources
See Regulation (EU) 2024/1781, particularly Articles 9–13 and Annex III; the European Commission’s Digital Product Passport FAQs; and its DPP Registry and standards update. Confirm current product-specific measures and referenced standards before implementation.
Editorial note: This guide describes data architecture and is not legal advice or a claim that one universal dataset applies to every product.