Model, batch or item-level DPP? Choosing the right granularity

Granularity is the first real architectural decision in a Digital Product Passport. The ESPR leaves it to the product-specific delegated act — and your business case may point somewhere else entirely. Model, batch and item are not a maturity ladder; they answer different questions.

One of the most important decisions in a Digital Product Passport architecture is granularity. What exactly are you identifying — a product model, a production batch, or one individual physical product?

There is no universal answer. Under the EU Ecodesign for Sustainable Products Regulation (ESPR), the applicable product-specific delegated act determines whether the regulatory Digital Product Passport must exist at model, batch or item level.

But regulation is only one part of the decision. A company may have a business reason to create a more granular product identity than the regulatory minimum — for example to support authentication, repair, returns, take-back or resale.

This guide explains what model, batch and item-level identity mean, when each level makes sense, and why more granular does not automatically mean better.

The short answer

Think of DPP granularity as three levels.

Model

One identity represents all equivalent products of the same model. Useful when the relevant information is the same for every equivalent product.

Batch

One identity represents a specific production batch. Useful when information differs between production runs, suppliers, locations, material lots or periods.

Item

One individual physical product receives its own unique identity. Useful when you need to know something about — or do something with — that specific physical object.

The important point is that these levels can form a hierarchy: model → batch → item. An item belongs to a batch, and a batch belongs to a model, where those concepts exist for the product concerned. This means a well-designed product-data architecture does not necessarily have to duplicate all information at every level.

What does the ESPR actually say?

The ESPR explicitly recognises all three levels. Article 9 states that the applicable delegated act must specify whether the Digital Product Passport is to be established at model level, batch level or item level, and define those levels for the product group concerned.

The regulation deliberately does not prescribe one level for every product. Its recitals explain why: the appropriate level should be assessed case by case, taking into account factors such as the complexity of the value chain; the size and nature of the products; their impacts; and the costs and benefits of establishing DPP information at model, batch or item level.

The objective is therefore not “make every product item-level”. It is to use the level appropriate to the product and its requirements.

Primary source: Regulation (EU) 2024/1781 — ESPR

What is model-level identity?

The ESPR describes a model as a version of a product whose units share the same technical characteristics relevant to the ecodesign requirements and the same model identifier.

In practical terms, imagine a Classic Blue Shirt — model CBS-01. Ten thousand equivalent shirts may be produced. At model level, they can share information such as:

• product name and description;
• design and specifications;
• material composition, where identical;
• care instructions;
• technical documentation;
• applicable certifications;
• other information common to every unit of that model.

Instead of creating ten thousand different identities, one model identity can represent the information shared by all equivalent products.

When does model-level make sense?

Model-level identity is particularly appropriate when:

• the relevant information is identical across all units;
• individual products do not need to be distinguished;
• production-specific differences are not relevant;
• no lifecycle process needs to interact with an individual physical item.

It is the simplest of the three levels. And where it satisfies the applicable regulatory requirement and the intended business use case, there may be no reason to make the identity more granular.

What is batch-level identity?

A batch represents a subset of products from a model that share a particular production context. The ESPR describes a batch, in general terms, as a subset of a specific model composed of products produced in a specific manufacturing plant at a specific moment in time.

Imagine the Classic Blue Shirt — model CBS-01 with batch 2028-04. The model information remains relevant, but the batch can add information specific to that production run. For example:

• batch or lot number;
• production date;
• production location;
• supplier information;
• material lot;
• sourcing or provenance information;
• test reports;
• production-specific certificates.

Why is batch-level useful?

Consider a company that manufactures the same product several times per year. The design may remain identical, while a material supplier changes; the manufacturing facility changes; a particular material lot is used; certificates differ; production dates differ; or test results relate to a particular production run.

Creating a completely new model for every variation would be inefficient. But storing everything only at model level could hide meaningful production differences. Batch-level identity provides the middle layer.

What is item-level identity?

At item level, one individual physical object receives its own unique identity. Instead of “Classic Blue Shirt” or “Classic Blue Shirt — batch 2028-04”, we now have Classic Blue Shirt — UID 8F73…

That unique identity allows information or events to be associated with one physical product rather than with every equivalent product. Examples include:

• a unique item identifier;
• individual product attributes;
• authentication events;
• ownership or registration, where appropriate and legally permitted;
• repair history;
• maintenance;
• condition;
• returns;
• take-back;
• resale;
• refurbishment;
• other lifecycle events.

This is where product identity starts to become particularly powerful beyond compliance.

Why item-level identity can unlock different applications

Suppose 20,000 identical jackets share one model-level DPP. A customer returns one jacket. At model level, the system knows what type of jacket it is. But it does not inherently know which individual jacket came back.

Now imagine every jacket has its own persistent identifier. The system can identify jacket UID 7F3A… That makes it possible to associate an event with that physical object: sold → returned → inspected → resold.

The same principle applies to repair. At model level: “this model can be repaired.” At item level: “this specific product was repaired on 14 March 2029.” Those are fundamentally different types of information.

A real-world example: return & resell

This distinction is already relevant in real-world DPP implementations. For Filou & Friends, Quifactum has deployed item-level Digital Product Passports that can support a return and resell workflow.

Why does item-level identity matter? Because resale concerns an individual physical garment. The workflow needs to distinguish this garment from every other garment of the same model.

An individual identity can connect the product to events such as: original product → first sale → return or take-back → assessment → resale.

The regulatory requirement and the commercial use case are therefore two different questions. A future delegated act might determine the minimum DPP granularity required for compliance. But a return and resell workflow can independently create a business reason for item-level identity.

Read the Filou & Friends case →

Identity granularity and data granularity are not the same thing

This is one of the most important architectural distinctions. Giving every physical product a unique identifier does not necessarily mean copying the entire product dataset into every individual product record.

Consider 10,000 identical shirts. The fibre composition — 100% organic cotton — may be identical for all 10,000. There is little value in maintaining that information independently 10,000 times if it can reliably be inherited from the model.

A more efficient architecture can look like this: the model contains information shared by all equivalent products; the batch references the model and adds information specific to the production run; the item references the relevant model and batch and adds only information specific to the individual object.

Conceptually, item data = shared model information + relevant batch information + individual identity + individual lifecycle events. This layered approach can reduce unnecessary duplication while preserving granular identity.

But there is an important regulatory caveat

The ESPR does not prescribe this particular data-inheritance architecture. The applicable delegated act determines which information must refer to the model, batch or item. A technical implementation must therefore ensure that the resulting DPP satisfies the applicable legal requirements regardless of how the underlying data is stored.

The EU Registry reinforces the hierarchy

The implementation rules for the EU Digital Product Passport Registry provide an interesting indication of how model, batch and item identities relate to each other.

Under Commission Implementing Regulation (EU) 2026/1778, where a DPP is created at item level, the corresponding batch and model identifiers should also be registered where batch and model concepts exist for that product. Similarly, where a DPP is created at batch level, the corresponding model identifier is required upon registration.

This creates a hierarchy: model → batch + model → item + batch + model.

For products that are unique by nature, such as certain handmade goods, the Regulation recognises that batch or model identifiers may not exist. The same Implementing Regulation also addresses products subject to several EU rules requiring registration at different granularity levels: in that situation, the DPP should be registered at the most granular required level.

This is important because it confirms that granularity is not simply a user-interface choice. It is part of the identity architecture behind the European DPP ecosystem.

Primary source: Commission Implementing Regulation (EU) 2026/1778 — DPP Registry implementation arrangements

Why not make everything item-level?

If item-level identity creates more possibilities, why not simply give every product an individual identity? Because granularity also creates operational consequences. Item-level identity can require:

• many more unique identifiers;
• item-specific data carriers;
• integration with production or labelling workflows;
• serialisation;
• additional data management;
• event handling;
• larger data volumes;
• more complex quality control;
• processes for damaged or replaced labels;
• lifecycle governance.

Imagine a company producing one million units. At model level, it may manage hundreds of DPP identities. At batch level, perhaps thousands. At item level: one million individual identities.

That can be entirely justified when the individual identity creates sufficient regulatory or commercial value. But complexity without a use case is simply complexity.

When model-level is usually enough

Model-level identity can be a strong choice when the main objective is to communicate information shared by equivalent products. Typical use cases include:

• product specifications;
• composition;
• general care instructions;
• manuals;
• technical documentation;
• common certifications;
• product-level transparency.

Ask: does anything important need to distinguish one physical unit from another? If the answer is no, model-level may be sufficient — subject, of course, to the applicable regulatory requirements.

When batch-level becomes useful

Batch-level identity becomes valuable when products are nominally the same but their production context matters.

Food and coffee

Different lots can have different origin, harvest, production date, roast date, ingredients or test results.

Textiles

Different production runs can involve different material lots, suppliers, factories, production dates or certificates.

Manufacturing

Quality tests or production records may apply to a specific run rather than to the complete product model. The batch becomes the natural unit of traceability.

When item-level becomes useful

Item-level identity becomes valuable when the business needs to interact with one specific physical object. Typical examples include:

• Authentication — is this the genuine physical product associated with this identity?
• Repair — what happened to this particular product?
• Maintenance — when was this individual asset last serviced?
• Returns — which product has been returned?
• Take-back — which physical item has entered the circular workflow?
• Resale — what is the history of this individual second-hand product?
• Warranty — which individual unit is involved in the claim?
• Product history — which events belong to this physical object?

The common characteristic is simple: the event happens to an individual physical object. That is the strongest reason to consider item-level identity.

Examples across sectors

Different sectors naturally lend themselves to different levels of identity.

These are examples of possible architectures, not statements of regulatory requirements for each sector. The applicable legislation always takes precedence.

How do you choose the right level?

A useful decision process starts with two separate questions.

Question 1 — what does regulation require?

Determine which legislation applies; whether the relevant requirements are already final; which DPP granularity is specified; and which information must exist at that level. That establishes the regulatory minimum.

Question 2 — what does the business case require?

Does the company need to know something about an individual production run? Does it need to interact with one specific physical product?

Use this simple framework: if the information is the same for every equivalent product, consider model. If information changes between production runs, consider batch. If events happen to individual physical objects, consider item. And always check the result against the applicable regulatory requirement.

A simple granularity decision tree

Does applicable legislation require a particular DPP level? If yes, that is your minimum. If no, or not yet defined, continue with the business case.

Does relevant information differ between production runs? If no, model-level may be sufficient. If yes, consider batch-level.

Do you need to identify or interact with one individual physical product? If no, batch-level may be sufficient. If yes, consider item-level.

Does the additional value justify the operational complexity? If yes, item-level can create significant lifecycle value. If no, use the least granular level that satisfies the regulatory and business requirements.

Can you start at model level and move to item level later?

Potentially — but architecture matters. A company may initially need only model-level identities and later discover valuable item-level applications. For example: phase 1, product information and compliance at model level; phase 2, production traceability at batch level; phase 3, returns, repair or resale at item level.

A well-designed identity and data architecture can make that progression easier. A poorly designed system may make it difficult if identifiers cannot be extended; product relationships are not preserved; model and batch structures are unclear; data is duplicated rather than structured; the data carrier cannot support the intended identity; or systems cannot exchange the relevant identifiers.

This is one reason to think about persistent product identity even when the initial DPP requirement is relatively simple.

Explore digital product identity →

Granularity is also a labelling decision

Moving from model to item-level identity does not only change the database. It can change the physical production process. At model level, many products may use the same data carrier. At item level, every physical object needs to be associated with its own unique identifier.

That can affect label generation; printing; QR code generation; RFID or NFC encoding; production-line processes; supplier workflows; quality control; packaging; and inventory systems.

This is why granularity should be decided early enough to understand its operational consequences. A DPP strategy cannot be separated entirely from manufacturing and labelling.

Granularity is not a maturity score

It is tempting to read model → batch → item as basic → better → best. That is the wrong interpretation. They solve different problems.

A model-level DPP can be the correct architecture. A batch-level DPP can be the correct architecture. An item-level DPP can be the correct architecture. The best choice is the level that satisfies the legal requirement and supports the intended use case without introducing unnecessary complexity.

Where Quifactum fits

Quifactum supports Digital Product Passports at model, batch and item level. The objective is not to push every company toward maximum granularity. It is to identify the level that fits the applicable regulation and the use case.

Product information can be connected from existing systems and supplier data, structured at the appropriate level, and linked to persistent product identities. Where item-level identity creates value, the same infrastructure can support lifecycle applications such as repair, returns, take-back and resale.

Explore the Quifactum platform →  ·  Discuss your use case →

Regulatory note. This resource is intended as a practical explanation of Digital Product Passport granularity and is not legal advice. Product-specific obligations should always be verified against the applicable legislation and delegated acts.

New to the subject? Start with What is a Digital Product Passport? or the EU DPP regulation & timeline.

Published by Quifactum. Last updated 21 September 2026. Regulatory content is reviewed against primary EU sources before publication.