DPP architecture guide

Digital Product Passport architecture: what has to be built

A working DPP is a product-data architecture that has to keep identity, evidence, access, updates, and lifecycle records usable for manufacturers, customers, authorities, suppliers, repairers, and recyclers.

Manufacturing companies often start with a simple question: where will the passport page live? The harder question is regulatory data governance: how the organization will keep required identifiers, compliance evidence, material updates, and lifecycle records verifiable over time. A Digital Product Passport has to connect a product to structured data, a stable identifier, a way to access the passport, evidence behind claims, traceability links, visibility rules, and update history.

Regulation sets the passport obligation and the categories of information that must be available. Architecture turns that obligation into a governed product-data system. The exact field list, access model, and assurance expectation depend on the product category and applicable delegated act, so implementation teams need a design that can handle today’s requirements without blocking later product-category detail.

This page explains the architecture behind a DPP: what has to be built, why each part exists, and what implementation teams should decide before passport data goes live.

Regulatory anchors and legal foundations

European passport rules require companies to treat product passports as organized, auditable data records. The regulatory anchors create a need for stable identity, access, product-specific data, evidence, traceability, and controlled updates. The architecture choices below describe how those anchors become a governed product-data system.

Digital product passport: ESPR Article 2, point 28 defines the DPP as product-specific data, with information specified in the applicable delegated act and accessible through a data carrier.
Data carrier and unique product identifier: ESPR Article 2, points 29 and 30 connect the physical access mechanism and the product identifier to the passport.
Battery passport: EU Battery Regulation Article 77(1) requires covered LMT, industrial, and electric-vehicle batteries to have an electronic battery passport from 18 February 2027.
Battery passport content: EU Battery Regulation Article 77(2) and Annex XIII point to both model-level information and information specific to the individual battery, including information resulting from use.
Unique identifier: EU Battery Regulation Article 3, point 66 defines the battery identifier as the string that identifies batteries and enables a web link to the battery passport.

These anchors explain why a DPP architecture has to do more than publish a page. The exact field list, access model, assurance expectation, and technical route still depend on the product category, delegated act, harmonised standards, and company-specific governance model.

Six core components of a DPP architecture

The EU Ecodesign for Sustainable Products Regulation defines a digital product passport as product-specific data, with information set by the applicable delegated act and accessible through a data carrier. The EU Battery Regulation applies the same broad idea to batteries and requires covered battery categories to have a battery passport from 18 February 2027.

Those legal definitions and passport obligations create practical design questions. A DPP architecture has to support the legal requirement while leaving room for implementation recommendation, product-category detail, and company-specific governance. In practice, this is what a DPP architecture has to do:

Identity: anchor the passport to the responsible organization and to the product, material, batch, battery, or item it describes.
Resolution: give people and systems a stable route from the data carrier and identifier to the passport, even if backend systems change.
Data model: separate product-category fields, static data, dynamic data, files, metadata, and linked records.
Evidence and traceability: connect claims to supplier declarations, certificates, calculations, batch records, material links, and assurance status.
Visibility: control which information is public, customer-facing, authority-facing, partner-facing, or restricted.
Lifecycle state: keep the passport usable as products move through sale, repair, reuse, repurposing, recycling, and data correction.

DPPs may be used across a long product lifecycle by people with different rights, questions, and responsibilities, not just at the point of sale.

1. Anchor the passport to the right product and responsible organization

A DPP needs two identity anchors.

The first is the responsible organization. Someone has to create the passport, control the data, grant access, update records, respond to customers or authorities, and maintain an audit trail. In practice this may involve several teams, but the system still needs a clear account or organization behind the passport.

The second is the product or asset identity. The passport may describe a product model, a material, a production batch, a battery, or an individual item. ESPR uses the concept of a unique product identifier. Battery passports use a unique identifier connected to the battery.

This component exists because passport data has to stay attached to the correct object over time. Batch-level evidence may support hundreds or thousands of items, but an individual item still needs its own stable identity if the passport will follow it through transfer, repair, second-life use, and end-of-life treatment. A battery passport, for example, may need to distinguish model-level information, batch evidence, and item-level lifecycle data.

Identity also affects versioning. The public identifier or link should continue to resolve even if the passport data changes. Older versions may need to remain auditable. Internal database IDs should not become the only way to find the passport. The architecture needs a stable identity model that works for public access, business access, system migration, and long product lifecycles.

2. Give people a stable way to reach the passport

The access mechanism connects the physical product to the digital passport.

A data carrier, often a QR code, gives users a visible way to reach the passport. But the QR code is only the entry point. The architecture also has to decide what the code resolves to, how long that address should remain stable, what happens if systems change, and how users can still access the passport if the visible code is damaged or replaced.

Access and visibility are separate decisions. A consumer scanning a code, a regulator checking required fields, a customer reviewing supplier evidence, and a recycler looking for end-of-life information may not see the same data. Some information can be public. Some can be restricted to the owner, customer, or authorized party. Some supply-chain information may be shared with downstream partners without exposing private commercial detail.

A practical access model therefore needs several controls:

Record-level access: can this viewer reach the passport at all?
Field-level visibility: which fields, files, links, and metadata can this viewer see?
Relationship-based access: does a supplier, customer, or downstream-chain relationship change what is visible?
Lifecycle status: is the record draft, ready, published, deprecated, corrected, or replaced?

A public QR code is simple. A controlled product-data environment that remains useful over years of ownership, repair, resale, and regulatory change is harder.

3. Use a product-specific data model

There is no single universal DPP schema that works for every product. The data model depends on the product category, regulation, delegated act, customer requirements, data owners, source systems, update frequency, visibility rules, and evidence expectations.

Templates are the practical way to manage that complexity. A template defines the structure of a passport: which fields exist, how they are grouped, which values are required, which files can be attached, and how imported data maps into passport records. Tabs and sections help human users work with the data. Field paths and schema mappings help systems import it correctly.

This component exists because manufacturing companies rarely create passport data in one place. Data may come from ERP, PLM, supplier files, calculations, certificates, lab results, or earlier records. The architecture needs repeatable import, validation, error handling, and field ownership so operational data can become passport data without losing context.

The data model should separate static data and dynamic data. Static data may be set at design, production, or first publication. Dynamic data changes during use or lifecycle events. Those categories often have different owners, update triggers, assurance needs, and visibility rules.

Files and attachments belong in this architecture too. Certificates, declarations, calculations, supplier documents, test reports, and other evidence may support specific fields or claims. Metadata such as source, timestamp, owner, uploader, workflow state, approval status, and assurance status helps users understand how much confidence to place in the data.

4. Connect claims to evidence and traceability

A passport claim is only useful if the reader can understand where it came from.

Evidence can appear in several forms: a field in the data model, an attached certificate, a supplier declaration, a calculation, a batch record, a linked certificate, a file, or metadata about the source of the data. The architecture should make those connections visible enough for the right user to assess the claim.

Evidence is not just an attachment. For each important claim, users may need to know whether the data is self-declared, supplier-provided, calculated, sampled, batch-level, item-level, verified, third-party certified, outdated, or superseded. Claim-level evidence with source, timestamp, owner, and assurance status makes the passport more credible and easier to audit.

Traceability adds the linkage structure underneath the passport. It connects products, materials, actors, certificates, batches, items, lifecycle events, and claims. For example:

An origin certificate records that a material exists, such as lithium from a specific source.
A product passport states that the product uses material from that origin.
The traceability link connects the product passport to the origin certificate.

In a longer chain, an origin certificate may connect to a smelter certificate, which connects to a producer’s product passport. A tree view can show upstream records. A history view can show how one passport or certificate changed over time.

Some implementations also need balance logic. An origin record may declare an available quantity of material. Downstream passports may consume quantities by linking back to that origin. Published downstream use can reduce the remaining balance, and exceeded values can flag cases where claimed use goes beyond the available origin amount.

5. Control access, updates, and versions

A DPP is an operating environment for controlled product data, not a static webpage.

The architecture needs rules for who can create a passport, edit fields, attach files, publish the record, grant access, view restricted data, correct errors, see history, and receive notifications. Those rules usually involve identity management, authentication, authorization, file storage, logs, reporting, tenancy, templates, and feature configuration.

Auditability is central. Teams need to see what changed, who changed it, when it changed, which source supported the change, and whether the change affected public, customer-facing, authority-facing, or restricted information. They also need to distinguish draft data from published data and current versions from older versions.

These decisions should be made before the first large import. If access rights, evidence files, templates, field ownership, and traceability links are added later, teams may have to rework data that is already live. Planning the control model early reduces avoidable operational risk.

6. Handle battery-passport detail where needed

Battery passports make the architecture more specific.

A battery passport may need model-level, batch-level, and item-level data. Model-level data can describe the design. Batch-level records can support shared production or material evidence. Item-level records anchor the individual battery that moves through sale, transfer, repair, repurposing, second-life use, and recycling.

This changes the architecture in three ways. First, identity granularity matters more because model, batch, and item records may all support the same passport. Second, dynamic technical data matters more because battery condition can change during use. Third, lifecycle status matters more because batteries may move through repair, reuse, repurposing, waste handling, and recycling pathways.

Battery passports also introduce lifecycle status and dynamic technical data. Some information is stable at production. Other information changes during use. Dynamic data may include remaining capacity, remaining usable energy, state of charge, state of health, internal resistance, cycle count, throughput, voltage, current, temperature, and time spent under extreme conditions. A controlled battery status model helps separate lifecycle state from those technical operating metrics.

The update pattern has to be controlled. The passport exists first, anchored by the battery identifier. Then authorized users or systems submit timestamped data for that battery. Invalid rows or readings may need to fail individually. Analytics may be useful for authenticated users or customers, while public visibility depends on regulation, business rules, and configured access rights.

What a mature DPP architecture should support

A mature DPP architecture publishes required fields and gives teams a controlled way to maintain product data over time. At minimum, it should support:

stable product and passport identity across system changes and lifecycle events;
product-specific templates, field paths, validation, and import rules;
claim-level evidence with source, timestamp, owner, and assurance status;
visibility rules for public, customer-facing, authority-facing, partner-facing, and restricted information;
traceability links between products, materials, actors, certificates, batches, items, claims, and lifecycle events;
version history and correction workflows;
clear separation between static data, dynamic data, files, metadata, and linked records.

These capabilities are partly technical, partly organizational. The point is not to add complexity for its own sake. The point is to avoid a fragile passport that is easy to publish once but hard to verify, update, explain, or maintain.

Three practical scenarios show why this matters

When a supplier certificate is replaced, affected passport claims may need review without erasing the earlier record. The old document should remain auditable, the old document should become superseded, the new document should become current, and the passport should show which claims depend on the changed evidence.

When material from several sources is blended into one production batch, the passport architecture needs a controlled way to connect source certificates, supplier declarations, calculated attributes, and available balances to the resulting batch. Downstream product passports can then rely on the batch evidence without losing the link back to the upstream sources.

When a regulator, customer, or recycler scans a product, the system should return the right data for that role. Public access, authority access, customer access, and partner access may all rely on the same passport identity while exposing different fields, files, and traceability context.

Implementation questions before a DPP goes live

Before publishing passport data, implementation teams should be able to answer:

Who is responsible for creating, controlling, and maintaining the passport?
What exactly does the passport describe: product, material, model, batch, battery, or item?
Which identifier remains stable across the lifecycle?
How does the data carrier resolve to the passport, and what happens if systems or links change?
Which fields are public, restricted, customer-facing, authority-facing, or shared with supply-chain partners?
Which template or data model applies to this product category?
Which fields are static, which are dynamic, and who can update them?
What evidence supports each claim?
How are files, certificates, metadata, traceability links, balances, and history connected?
How are corrections, new versions, deprecated records, and replaced passports handled?
Can users tell the difference between self-declared, supplier-provided, calculated, verified, and externally certified data?

Official regulatory references

For the legal text behind the architecture, start with the official EUR-Lex pages for the Ecodesign for Sustainable Products Regulation and the EU Battery Regulation. The Minespider term pages above explain the implementation concepts, while these official sources remain the primary legal references.

Closing

A Digital Product Passport brings product data into a controlled architecture. The architecture has to connect responsible organizations, stable product identity, access mechanisms, product-specific data models, evidence, traceability, permissions, and version history.

That is what makes the passport useful beyond a first scan. It gives manufacturing companies a way to organize product and supply-chain information so the right people can find, understand, verify, and maintain it across the product lifecycle.