A Digital Product Passport is a governed data interface, not a QR-code page
The EU Ecodesign for Sustainable Products Regulation (ESPR) establishes the Digital Product Passport framework, but the exact data required for a product group comes from applicable delegated acts. That distinction matters architecturally. A DPP platform should not hard-code one universal passport schema and assume every product will share it.
Articles 9–11 of Regulation (EU) 2024/1781 define core principles: the passport can be specified at model, batch or item level; it is connected to a persistent unique identifier through a data carrier; data should be accurate, complete and up to date; access can differ by actor; and the system is expected to use open, interoperable, machine-readable approaches. The software challenge is therefore identity, schema governance, access control and durable availability.
1. Separate product identity from passport version
A product identifier answers "what object is this?" A passport version answers "what data was valid for this object under this schema at this time?" Keep them separate. A stable product, batch or item identity can have multiple passport versions as data is corrected, delegated-act requirements evolve or lifecycle information is added.
2. Make model, batch and item levels explicit
| Level | Typical use | Architecture implication |
|---|---|---|
| Model | Shared design/specification data | One identity referenced by many physical units |
| Batch | Production-run or material evidence | Lineage and manufacturing context |
| Item | Individual serialised object | Lifecycle/service history can be unique |
Do not guess the legally required level globally. Store the level as part of the passport definition and allow product-group policy to decide which identity type the data carrier resolves.
3. Treat the data carrier as a resolver, not the database
A QR code, barcode or other permitted carrier should resolve a persistent identifier. The carrier does not need to contain the full passport. This allows information to evolve while the physical reference stays stable. The resolver layer should protect against broken links, redirect safely to the canonical passport endpoint and support locale or actor-aware presentation without changing identity.
4. Use schema packages instead of one giant JSON document
A maintainable DPP platform needs a registry of schema packages: field definitions, units, validation rules, vocabulary, required/optional status, access class, provenance expectations and the product-group rule that activated the field. Each passport version references the schema version it was validated against.
This creates a clean migration path. New requirements do not require rewriting historical passport data in place; they create a new schema version and a controlled migration or enrichment workflow.
5. Access rights belong in policy, not in the frontend
ESPR explicitly anticipates different actors having access to different passport data. Implement access at the API/domain layer. A consumer view, manufacturer workspace, repairer interface and authority view can expose different fields from the same canonical passport record.
For sensitive or restricted data, record why an actor has access, which policy granted it and whether data was exported. Frontend hiding alone is not access control.
6. Model who may create or update each field
A DPP is multi-party by nature. Some data may originate from the manufacturer, supplier, certifier, repairer or another authorized actor. Store field-level or section-level provenance: source organization, actor, timestamp, source document/API and verification state. Where a value is derived, record the derivation method rather than presenting it as direct evidence.
7. Design availability and backup as product requirements
The regulation requires durable availability and contemplates backup through a DPP service provider. Architect for lifecycle longer than a marketing website: stable identifiers, exportable data, recovery procedures, provider exit, domain changes and organization failure scenarios. A DPP should not disappear because a SaaS subscription or frontend deployment ended.
8. Interoperability requires controlled semantics
"Open format" is not enough if two systems use different meanings for the same field. Maintain canonical units, code lists, vocabularies and mapping rules. API contracts should expose schema/version identifiers so downstream systems can validate what they received.
9. Keep DPP separate from general traceability, but connect the graphs
Traceability answers where material or product state came from and how it moved. A DPP is a regulated information interface for a product identity. They overlap, but they are not the same bounded context. Connect them through stable IDs and evidence references rather than forcing one table to serve both jobs.
For a broader compliance/traceability architecture, see our EUDR/DPP/traceability pillar and the Supply Passport OS proof. For implementation, see Compliance & Traceability Software Development.
DPP architecture checklist
- Stable product/batch/item identity separated from passport version.
- Configurable identity level per product-group rule.
- Data carrier resolving a persistent identifier.
- Versioned schema registry and validation rules.
- Server-side actor access policy.
- Field/section provenance and update authority.
- Long-lived availability, backup and provider-exit strategy.
- Open, machine-readable and semantically controlled integrations.