How many passports a range needs, and why it is not settled

What is established, proposition by proposition

The table below separates the propositions and gives each one its own state. The states are not opinions about likelihood. They record what kind of document each proposition rests on.

Two of those rows use unresolved language on purpose. Where the estate cannot settle a proposition it says so and records where it looked, and the method behind that is set out on how we know.

The registry already assumes the ladder

The strongest thing that has changed here is not an opinion about which level will win. It is that a working registry has been built on the assumption that all three exist.

The registry confirms that the three levels are a real structure rather than a drafting convenience, because a system has been built that accepts records against each of them. It also confirms that they are expected to coexist, which is a different proposition from choosing one: a business may end up holding a model record and item records underneath it, joined. What it does not do is pick a level for textiles, and reading it as though it had is the commonest error currently in circulation about this instrument.

The consequence lands before any product act does. If you hold batch information with no reliable way to say which model it belongs to, you are not merely undecided about a level, you would fail a linking requirement that is already in force for anybody registering. What a registration contains, and what a business has to be before it can make one at all, is set out on registering a passport.

The Registry implements the ladder, but the product rule chooses the rung

Regulation (EU) 2026/1778 builds model, batch and item into the Registry architecture. It does not turn one of those levels into the universal DPP default.

Article 8 says the level applicable to a product is the level provided by the relevant product-specific delegated act or other Union law. If the same product is subject to rules at different levels, the Registry arrangements use the most granular level. It also supports links from an item to its batch or model, and from a batch to its model, where those objects exist.

The current Commission interface illustrates why UI state is not the same thing as cross-category law. As checked on 7 October 2026, User Guide v1.03 presents Batteries as the first product group and says only item level is currently available and pre-selected for that workflow. That is the currently defined level for the Battery registration flow described by the guide. It is not evidence that textiles, iron and steel, construction products or future ESPR DPPs will all be registered at item level.

Do not hard-code the current Registry UI's item-only Battery state as a universal DPP architecture rule. Keep model, batch and item identifiers available as separate relationship concepts even if the first operational product group only exposes one registration level.

For the current registration journey use How to register a DPP in the EU Registry, and for the wider picture the Registry Operational State Snapshot.

The arithmetic, and the half of it that is not yours to choose

The gap between the levels is easiest to see on a single style, and the arithmetic below is an illustration rather than a measurement. Take one style sold in five sizes and six colours, produced in two runs, with 1,200 garments made in total. Those numbers are assumed because they divide cleanly. They are not drawn from anybody's catalogue and nothing in the table is a finding.

The outer spread is between one record and 1,200. The more awkward spread is the one inside the first two rows, where the same word produces either one passport or thirty depending on what a model is taken to mean. That ambiguity deserves more attention than it gets, because it sits inside the answer most people assume is the safe one.

The thirty is not a modelling choice. It is imposed by the numbering scheme's own management standard, whose worked example makes each style, colour and size variation a distinct identifier. A business does not decide whether a size and a colour need separate identifiers any more than it decides its own postcode. That settles half of the argument this page is having: the identifier count for a given catalogue is a scheme rule, and a vendor arguing about it with you is arguing about the wrong document. What that standard asks, what allocation costs and why the answer depends on which country allocated the numbers is set out under identifiers.

The two questions still have two different answers. Identifier allocation follows the scheme and what the selling channels enforce. Passport granularity follows the product act. It may land on the same unit as the identifier and it may not, and treating the identifier count as the passport count builds an assumption into the plan at exactly the point where the plan becomes expensive to change, because carriers get printed onto goods that then go into circulation.

None of this changes the amount of information a garment needs behind it. A composition is one fact whether it is published once or twelve hundred times, and a worked passport shows what one of those records holds. What the level changes is how many records exist, how many carriers get printed, how long the records have to be kept reachable and what happens when one of them turns out to be wrong.

The level that is missing, and what it costs

Model, batch and item contain no variant level. A model is a style. A batch is a production run. An item is one physical garment. A colourway is none of those three, and that is where the model breaks in ordinary use rather than in a hard case.

The failure looks like this. One style is made in six colours, and a claim is true of some of them and not the others: recycled content in the black but not the ecru, a certificate that covers one dyehouse, a substance restriction met by four finishes out of six. At model level the record has two options and both are wrong. It can assert of the whole style what is true of part of it, which overstates. Or it can drop the claim entirely, which loses a fact the business paid to establish and can prove.

The batch level does not rescue it, because the join is lossy in the direction that matters. Reading upward is easy: from a batch you can always say which model it belongs to. Reading downward is the hard direction, and it is the one a passport needs. From a model record, or from a garment in a customer's hand, you cannot say which run it came out of unless something was captured at the item at the time it was made. So a claim that is true of one run cannot be attached after the fact to the units that came out of it.

What survives that is item-level credentials, which is the most expensive answer on the page and the one nothing has yet required. A per-variant claim has no clean representation in a structure built from models, batches and items. Three routes lead out of it: hold the claim at the item, split the model so that each colourway is its own model, or stop making the claim. Most catalogue systems have already pushed businesses part of the way down the second route by putting the identifier on the variant and the descriptive fields on the product, which is why the split feels natural in a shop and awkward in a passport. Where those fields sit in one common system is worked through under Shopify.

None of that is an argument for buying item-level identity now. It is an argument for knowing, before anybody quotes you, which of your claims are true of a whole style and which are true of part of one. That inventory takes an afternoon and costs nothing. It is also the thing that decides whether the cheapest level is available to you at all.

What a price per passport is actually pricing

A price expressed per passport is a price for a quantity nobody has fixed. The quantity moves by three orders of magnitude between the answers on this page, and the reader is the party carrying that risk.

The nearest thing to a published price in this territory is identifier allocation. Across the national member organisations of the numbering scheme whose fee pages we read, one prices by turnover band with an allocation capacity attached, one prices by capacity band combined with turnover and one states its fee as independent of the number of codes altogether. Not one of the three prices an identifier individually.

We went looking for a published self-serve price per unit for passport preparation from a European provider and did not find one. That is a statement about where we looked rather than a claim that none exists anywhere. It is consistent with what the published cost material does show, which is pricing by subscription and by band, and the figures that do exist are set out with their publishers on what the work costs.

The gradient across the three levels

Cost does not rise evenly as you go down the ladder, and it is more useful to know the shape than a number nobody has measured. Published here as a shape, because the material we read carries fee structures rather than prices per product, and because no cost per product for this work appears anywhere on this site.

• The evidence half is close to flat. A composition, an origin and a supplier document are the same facts at model, batch and item level. Establishing them once is most of the work and it does not multiply.
• The identifier and carrier half rises with the count. Allocation, artwork, printing and the checking that goes with them all move with how many distinct things exist, which is exactly the dimension the scheme rule above has already settled for identifiers.
• Keeping and correcting rises fastest. A wrong value in one model record is one correction. The same wrong value at item level is a correction exercise across everything already in circulation, and carriers already printed cannot be recalled.

If the model level holds for textiles, an item-level commercial argument has no basis in the regulation. It may still have a basis in something else, in anti-counterfeit work, in warranty, in a service a business wants to offer, and those are real reasons that should be argued on their own merits. What they are not is a compliance requirement, and a proposal that presents them as one is describing a decision that has not been taken.

What has been proposed, and what a proposal is

A study prepared to inform the textile decision is the document everybody quotes here, and it is worth reading. What we read in it does not fix a level. It sets out the same three levels the framework names, and it says that where possible the granularity required should be aligned with the traceability practice already established in the value chain. That is a proposal about method rather than a proposal of an answer. Either way a preparatory study exists to be argued with, and the act it informs may take it up, vary it or set it aside.

Two things circulating as findings from that study are held back here. We could not obtain the sections that would carry a proposed level for apparel, so this page attributes no level to it. The other is a claim that the study's identification block names a serialised trade item number, an identifier that distinguishes one physical article from another. In the part we read it does not. The identification concepts there are a unique product identifier, a unique operator identifier and a unique facility identifier, with no serialised form specified.

The sector's trade association has published a position on granularity as well. An industry position is evidence about what part of an industry is asking for, and it is never evidence about what an act will require. Both of those documents are useful for understanding the argument. Neither of them ends it.

Timing gets merged into this argument constantly. An act being adopted is not an act applying: the framework sets a floor of no less than eighteen months between a product act entering into force and applying, except in duly justified cases. That is arithmetic rather than a date, and this page resolves it into no year. What has happened, with sources and verification dates, is maintained on the status tracker, which is the destination here that carries dates.

What to do while the unit is open

An open question is not a reason to wait, because almost all of the preparatory work is the same under all three answers. The exceptions are the decisions that are hard to reverse, and those are the ones worth holding.

1. Record every fact at the level it is actually true. A composition belongs to the style. A dye lot belongs to a run. A wear mark belongs to one garment. Facts filed where they belong can be rendered at whichever level the act picks, and facts flattened onto the wrong unit have to be collected again.
2. Write down which of your claims are true of part of a style. That list is the variant gap in your own catalogue, and it is the input to every later decision about level. It costs nothing to make now and it cannot be reconstructed later from records that never carried it.
3. Keep the unit you sell apart from the unit you record. They are separate columns in the same spreadsheet and they answer to separate rules. Merging them is the cheapest mistake to make now and one of the more expensive to unpick later.
4. Make sure a batch record can always name its model. Linking upward is already required of anybody registering at more than one level, and it is far easier to capture at the time than to reconstruct.
5. Do not print anything that assumes an answer. A carrier on goods in circulation cannot be recalled, and a serialised carrier commits you to a level before anybody has chosen one.

None of that is wasted if the act picks a level nobody expected. That is the test worth applying to any preparation you are asked to pay for now: whether it survives all three answers, or whether it quietly bets on one.

A textile record that keeps each fact at the level it is true can be rendered at whichever level the act picks.

Digital Product Passport Granularity: Model, Batch or Item?

A Digital Product Passport is not universally item-level. The applicable product law determines the level at which the passport operates. ESPR expressly allows product-specific measures to specify model, batch or item level.¹ Adopted DPP regimes already prove that different answers are possible:

• batteries use a hybrid model with model information plus individual-battery lifecycle data
• detergents are model-level by default
• toys are model-level by default
• construction products use product-type architecture
• final textile granularity is not yet adopted.

The question is:

What regulatory object does this passport represent, and which data belong at model, product-type, batch or individual-item level?

All categories: Digital Product Passport Requirements by Product Category.

The levels in plain English

A product can have multiple identifiers in its business systems without its legal DPP being item-level. Granularity is about the regulated passport object and where the information attaches.

Granularity is not a language question

Granularity answers which product gets a passport. It does not mean each language needs another product identity. See how one DPP can support different EU markets and languages.

ESPR: the product-specific act decides

ESPR Article 9 requires the applicable product-specific delegated act to determine whether the DPP corresponds to the model, batch or item.¹

That rule is a direct warning against building one universal item-serialisation assumption into a DPP platform.

Batteries: a genuine hybrid model

The Battery Passport is the strongest adopted example of a hybrid architecture.²

It combines:

• information that belongs to a battery model or broader product description
• information specific to an individual battery
• information that can be updated during that individual battery's life.

Individual lifecycle data include territories such as:

• state of health
• battery status
• charging/discharging cycles
• negative events
• operating conditions.

The battery regime also provides continuity when a battery is prepared for reuse, repurposed or remanufactured: a new passport can link back to the original passport or passports.²

That sophistication is category-specific.

Battery proves that DPPs can carry item/lifecycle data. It does not prove that every DPP must.

Detergents & surfactants: model-level by default

The Detergents and Surfactants Regulation says the DPP corresponds to a specific model of detergent or end-user surfactant.³

The model concept is tied to characteristics including the manufacturer, trade name, content and manufacturing processes, relevant classification and a type number or other group identifier.

There is a controlled interoperability exception: where another applicable Union DPP obligation requires the product to operate at batch or item level, the detergent DPP can align to that level.³

Model-level by default, with alignment to batch or item level where another applicable Union DPP law requires it.

Toys: model-level, with a controlled batch interaction

The Toy Safety Regulation says the DPP corresponds to a specific toy model.⁴

Where other Union law requires a DPP for the same toy at batch level, the Toy DPP can correspond to that batch level. The Regulation also provides for handling overlapping Union DPP obligations.⁴

A data carrier attached to an individual toy does not by itself transform the DPP into an item-level passport.

Operationally, physical placement of a carrier and legal data granularity are not the same decision.

The common DPP Registry does not change that legal starting point. It supports registration at model, batch and item level and uses the most granular level required by the applicable law.

Registry capability and product-law granularity must be read in the right order. For toys, the product rule supplies the model-level default and its controlled batch interaction. The fact that the Registry can technically hold an item-level identifier does not create a universal item-level Toy DPP requirement.

This is a useful implementation rule beyond toys too: design your identity hierarchy so model, batch and item can coexist, then let the applicable product law choose which rung the passport must occupy.

Construction products: product-type architecture

The Construction Products Regulation uses a product-type DPP architecture.⁵

This is another adopted counterexample to the idea that the future EU DPP world is simply one serialised passport per physical object.

The construction system still needs delegated implementation. But the legal architecture already shows that “product type” is a meaningful regulated granularity in its own right.

Textiles: final granularity is not yet known

The textile DPP delegated act is planned for Q4 2027 and has not been adopted.⁶

The JRC's May 2026 preparatory work explores a mixed architecture in which different information may sit naturally at different levels.⁷

That is useful design evidence, not final law.

Textile granularity is in official development. A universal item-level textile passport is not established by current evidence.

Businesses can prepare their internal model, variant, batch and item relationships now without claiming to know which one the final act will choose.

Can one QR code serve multiple products?

The better question is: what does the carrier resolve to and what level does the applicable law require?

If a DPP is model-level, many physical units can be associated with the same model-level passport architecture, subject to the specific carrier and identification rules. That does not mean one loose QR code can be arbitrarily reused without controlled identity.

If the law requires individual item identity or lifecycle data, each individual object needs the identity architecture necessary to distinguish it.

So:

• a model-level DPP can represent multiple physical units
• item-level DPPs need individual identity
• carrier placement and uniqueness must still follow the applicable law and technical rules.

See Digital Product Passport Identifiers: UPI, GTIN, QR Codes and GS1 Digital Link.

Why granularity changes the data model

Granularity is not just a printing decision.

It determines:

• which attributes are inherited from a model
• which values can differ by batch
• which events attach to an individual item
• how corrections propagate
• how many identifiers need to be managed
• how lifecycle updates work
• what happens when a product is repaired, remanufactured or split into new regulated objects
• how the Registry and carrier identity relate to the underlying record.

An item-level architecture built where the law only needs model-level information can create unnecessary cost and data complexity. A model-only architecture built where item lifecycle data are legally required can fail the opposite way.

Complex products can link hierarchies without deciding the legal passport level

A complex product can have a rich technical hierarchy without that hierarchy deciding how many legal DPPs the product needs.

Digital-twin standards and AAS implementations can represent assemblies, subassemblies and components in nested or federated structures. Catena-X also supports relationships between digital twins across company boundaries. Those patterns are useful when a manufacturer needs to preserve a bill of materials, trace component relationships or connect information held by several organisations.

But a technical relationship is not a legal granularity rule.

A bill of materials might contain hundreds of components. That does not mean every component automatically needs its own DPP. Equally, a model-level DPP requirement does not prevent the underlying architecture from keeping item, batch or component relationships where they are operationally useful.

The two decisions should be made separately:

That separation makes the existing hierarchy first, legal level second approach more useful, not less. Build a product hierarchy that can represent the real product. Then let the applicable delegated act or sector rule choose the passport level instead of inferring it from the BOM or digital-twin structure.

For the representation side of that decision, see Digital Product Passport vs digital twin vs Asset Administration Shell.

A useful implementation pattern: hierarchy first, legal level second

Before final product-specific rules are known, businesses can safely model the hierarchy:

PRODUCT FAMILY
    ↓
MODEL / STYLE
    ↓
VARIANT
    ↓
BATCH / LOT
    ↓
ITEM / SERIAL

The exact hierarchy will differ by sector. The principle is to avoid flattening all identity into a single SKU field.

That lets the final DPP rule select the relevant level without forcing a complete data rebuild.

Granularity is also a scope-and-change question

Two records can look identical on launch day and still need different granularity because they change differently over time.

A static model fact

A toy model's legal identity, CE-related references or specified model information can be shared by all units represented by that model-level DPP. Repeating the same governed value thousands of times at item level does not make the fact more accurate.

A batch-dependent fact

A production lot can have a different supplier, formulation, facility or test result from the previous lot. If the applicable regime or the underlying compliance evidence is batch-sensitive, the data model needs a batch relationship even if the public DPP itself is not ultimately defined at batch level.

An item lifecycle fact

A battery's state of health can change because of the history of that individual battery. It can't safely be recorded once at model level and left there.

So your own product records may need more levels than the legally visible passport. The purpose is not to over-serialise. It is to preserve enough structure to publish the right legal view when the applicable rule is known.

Granularity, identifiers and access should be designed together

A change from model to item level can change:

• how many UPIs or serial identifiers are required
• whether the same carrier can be used across multiple units
• which Registry relationships need to be maintained
• how updates are written and audited
• which information is public versus restricted
• what happens when an item is repaired, repurposed or replaced.

The granularity decision should connect to Digital Product Passport Identifiers and Who Can See What in a Digital Product Passport?, rather than be treated as a standalone label-printing choice.

What happens when a value changes?

The answer depends on the level at which the fact is true.

If a model-level specification is corrected, every unit represented by that model may need to resolve to the corrected model fact, subject to version and legal-history requirements.

If a batch-specific test result changes, the correction should not silently overwrite unrelated batches.

If an individual lifecycle event is recorded, it belongs to that item and should not be propagated to every product sharing the same model.

A useful system stores both:

• the value
• the level and scope at which the value is true.

That principle remains useful even where the final product-specific DPP granularity is still in development.

What should ecommerce and product-data teams design now?

PREPARE

Define model and variant rules. Know which changes create a different model versus a commercial variant.

Retain batch relationships. Do not discard production-lot relationships simply because today's online catalogue is model/SKU based.

Support serial identity where it already has business value. For assets, regulated goods or repairable products that already carry serials, preserve the relationship. Do not make serialisation universal merely for DPP speculation.

Separate inherited from instance data. A model fibre composition and an individual battery state-of-health value are structurally different facts.

Keep lifecycle events separate from static attributes. This is essential for regimes such as batteries.

WATCH

• final textile granularity
• tyre and aluminium delegated acts
• iron and steel delegated act
• construction delegated implementation
• future product acts that introduce batch/item interactions.

DO NOT HARD-CODE

• every DPP = item passport
• every QR = unique item identity
• SKU = legal model definition
• battery lifecycle design = template for all sectors.

Direct answers

Does every physical product need its own DPP?

No. Adopted regimes already use model and product-type architectures as well as hybrid item/lifecycle approaches.

What is model-level?

One DPP corresponds to a legally defined model and can describe multiple physical units sharing that model.

What is batch-level?

The passport/data attaches to a defined production batch or lot rather than only the model or each individual unit.

What is item-level?

The passport identifies an individual physical unit, usually with a unique serialised identity.

Why are Battery Passports different?

Battery law deliberately includes individual lifecycle information as well as model information.

Is textile granularity known?

No. Official preparatory work exists, but the final textile delegated act has not been adopted.