How Should Textile Brands Structure Product, Variant, Batch and Item Data Before Final DPP Rules?

Why textile brands need a hierarchy before final DPP rules

Waiting for every textile DPP detail to be final would solve one risk by creating another.

Brands already need to answer basic operational questions:

• Which records describe the same design?
• Which values change by colour or size?
• Which goods came from a particular production run?
• Which evidence applies to one run rather than the whole style?
• Which identifier belongs to a sellable variant?
• Can one physical unit be distinguished from another if a repair, return or resale process needs it?
• If a supplier changes, what product facts should change with that supplier?

Those questions exist independently of the DPP.

The risk is not organising product data too early. The risk is organising it around an unverified assumption about the final regulation.

A data model that collapses style, SKU, batch and item into one record may work while a catalogue is small. It becomes expensive when the same product has multiple colours, sizes, production sites, material changes or replenishment runs.

A data model that creates a unique regulatory passport record for every physical unit before there is a business or legal reason to do so can create the opposite problem: unnecessary identifier, carrier and lifecycle infrastructure.

The better approach is to preserve the hierarchy first, then let the final regulatory rule decide which level becomes the passport level.

Product, model, variant, SKU, batch and item are not synonyms

There is no reason every company's commercial vocabulary must match another company's. The important thing is to define what each object means in your own data and not use one field to stand for several different things.

ESPR is clearer than many market summaries on the last point. Its Article 9 says product-specific delegated acts are to specify whether the DPP is established at model, batch or item level, including the definition of those levels for the product group.²

That is why "SKU-level DPP" should not be used as a substitute for "item-level DPP". A SKU might represent "navy, medium". There may be 4,000 physical navy-medium shirts with the same SKU. Item level means being able to address one of those physical shirts as a single unit.

What is legally known today

Three things are particularly useful for data architecture.

First, ESPR establishes the horizontal DPP framework. Where a product-specific DPP is required, the applicable delegated act can specify the data, carrier arrangements, access and whether the passport is model, batch or item level.²

Second, textiles are on the current ESPR development track. The Commission currently gives Q4 2027 as the indicative adoption timing for the textile delegated act.¹ That is a planned act date. It is not, by itself, a textile DPP compliance deadline.

Third, official preparatory work is examining textile-specific data and system choices. The May 2026 study explicitly discusses model, batch and item granularity. It also explores an inheritance model in which an item-level identifier could, if that approach were chosen, point initially to data inherited from batch or model level.³

That third point is useful because it demonstrates a technically credible way to separate identifier granularity from the scope at which every fact is collected.

It is still a study proposal.

The study itself says it supports preparation of a future delegated act and that its findings require further validation and refinement. It does not create legal requirements.³

What is not yet fixed

For textiles, do not currently present any of the following as final simply because it appears in preparatory work or industry proposals:

• the final textile DPP field list
• the final legal definition of textile model, batch or item
• whether every covered textile will need an item-level passport
• whether every size or colour must have a separate passport
• the final identifier arrangement
• the final data-carrier arrangement
• the final access rights for each data field
• the final rule for inheritance between levels
• the final application date.

This does not make official preparatory material unimportant. It changes the label that should be attached to it.

Official development evidence can guide a flexible architecture.

It should not be converted into adopted law.

A low-regret textile data hierarchy

A useful architecture has four separable levels.

1. Product or style

This is the stable commercial or design parent.

Typical candidates for this level include:

• internal style code
• product family name
• core design description
• brand
• stable construction attributes
• base care logic where it is genuinely shared
• links to higher-level specifications.

Do not force facts onto style level because it is convenient. If a fact differs by colour, material option or factory run, store it lower.

2. Variant

Use variants for attributes that create a distinct sellable or technically distinct version.

Examples include:

• size
• colour
• fit
• material version
• finish
• market-specific configuration
• variant SKU
• variant commercial identifier where used.

Some brands model colour and size as separate sub-levels. Others use one combined variant object. Either can work if the relationships are explicit.

The important point is that the model can answer:

Which facts are common to all versions, and which facts change for this version?

3. Production batch

Create a real production-batch object rather than storing a batch code as an unexplained text field on the product.

A batch record can link to:

• production site
• production period
• purchase or work order references
• supplier lot references
• material lots where available
• batch-specific test evidence
• inspection evidence
• batch-specific certificates where they genuinely apply
• quantity produced
• manufacturing changes or deviations.

The May 2026 textile study describes batch level in the context of a subset of a model produced in a specific manufacturing plant at a specific time under common conditions. That is development evidence rather than a final textile legal definition, but it is a useful reason to keep production batches distinct from logistics batches.³

4. Physical item

An item record represents one unit.

Only create rich item-level records where they have a real use.

Possible uses include:

• unique serial or item identifier
• authentication
• repair history
• resale
• rental
• ownership-neutral service history
• individual quality event
• return or recall resolution
• later lifecycle updates.

A brand does not need to collect item-specific values for every product attribute merely because it chooses to reserve or assign an item identifier.

That distinction is one of the most important ways to avoid over-engineering.

Where identifiers fit

A hierarchy without identifier scope quickly becomes ambiguous.

For every identifier, store at least:

• identifier value
• identifier scheme or type
• entity identified
• granularity
• issuing party or namespace where relevant
• validity or status
• source
• date created or verified.

A style code should identify the style.

A SKU should identify the stock object your system says it identifies.

A batch ID should identify a production batch.

An item ID should identify one unit.

Do not make an identifier do several jobs simply because the same string can be printed on a label.

Is GTIN the DPP identifier?

Do not assume so.

ESPR's DPP architecture requires the relevant delegated act to specify the unique product identifier at the required level. Annex III includes GTIN or equivalent among the information that a product-specific act can draw on.²

That is not the same as a universal rule that every textile DPP must use GTIN as its unique product identifier.

A GTIN can still be extremely useful in commercial product identity. The safe architecture is to store it as a typed identifier linked to the entity it identifies, rather than making the whole data model depend on it being the future regulatory identifier.

How product facts should inherit across levels

Inheritance reduces duplicate data. Scope prevents false precision.

Use both.

A practical rule is:

A lower-level object may inherit a fact from its parent only while there is no more specific fact that validly overrides it.

For example:

Style-level fact "Oxford shirt, long sleeve" may be common across all variants.

Variant-level fact Colour is navy for one variant and white for another.

Batch-level fact This production run was made at Facility A during August 2026 using supplier lot references X and Y.

Item-level fact This physical shirt received repair event R-104 in 2029.

The same principle applies to evidence.

A certificate covering one facility and one production period must not silently become evidence for every future batch of the style.

A composition declaration that applies to all colour variants can be linked at the common parent. If one colourway has a different fibre composition or treatment, that variant needs a more specific value and evidence scope.

How evidence should be scoped

A product fact without scope is difficult to govern.

For each material assertion, keep:

• the value
• the entity it describes
• effective dates
• the evidence source
• the issuer
• the evidence date
• which products, variants, batches or items the evidence covers
• whether the source is a declaration, test, certificate, system record or calculation
• whether another source conflicts with it
• when it should be rechecked.

This matters even if the future DPP requires only model-level publication.

The passport may display one value while your evidence system still needs to prove why that value is valid for the relevant units.

Do not confuse publication granularity with evidence granularity.

Batch data is different from item data

Batch data answers:

What was true about this production run?

Item data answers:

What happened to this physical unit?

Those are different jobs.

Batch-level data is often useful for:

• factory and production-run traceability
• test results
• quality inspection
• production changes
• targeted investigation
• links to material lots.

Item-level data becomes more useful where the unit has a life after the initial sale:

• authentication
• repair
• refurbishment
• rental
• resale
• individual service events.

The May 2026 study notes that item-level practice is currently less common across the textile sector than model and batch practices, while discussing item-level identifiers as a possible future architecture.³

That is a reason to keep the data model extensible, not a reason to create full item-level infrastructure for every garment now.

What ecommerce systems already know

Most ecommerce platforms already contain part of this hierarchy.

They often know:

• product title
• product or style record
• variants
• option values such as size and colour
• SKU
• barcode or GTIN field where used
• price
• inventory
• images
• market availability.

That is useful, but it is not the whole regulatory product model.

Ecommerce systems commonly do not natively express:

• production batch
• manufacturing site tied to a batch
• supplier evidence scope
• certificate validity
• test provenance
• regulatory status of an attribute
• conflicts between sources
• item lifecycle
• whether an attribute is inherited or overridden.

Do not discard ecommerce data. Treat it as one source in a wider governed product model.

A sensible mapping layer can connect:

commerce product → commerce variant → governed product/variant → production batch → optional item

without pretending the ecommerce platform is itself the DPP data model.

What businesses should avoid hard-coding

DO NOT HARD-CODE: every item gets its own legally required textile DPP

That is not final law.

DO NOT HARD-CODE: SKU equals legal model

A SKU is a commercial object. The future delegated act defines the legal granularity.

DO NOT HARD-CODE: every size and colour needs a separate passport

A change may matter to the product data without necessarily creating a separate legal passport. The final textile rule must decide that.

DO NOT HARD-CODE: every fact lives at one level

Composition, facility evidence, test evidence and lifecycle events can legitimately have different scopes.

DO NOT HARD-CODE: one identifier replaces all others

Style IDs, SKUs, GTINs, batch IDs and item IDs serve different purposes.

DO NOT HARD-CODE: preparatory-study fields are statutory fields

They are development evidence until adopted law says otherwise.

Worked example: one shirt, many data levels

Consider a fictional style:

Harbour Oxford Shirt, style HS-100

It is sold in navy and white, in sizes S to XL.

A low-regret structure could look like this:

STYLE HS-100
Harbour Oxford Shirt
│
├── VARIANT HS-100-NVY-M
│   colour: navy
│   size: M
│   SKU: HSO-NVY-M
│   commercial identifier: [typed value if used]
│
│   ├── BATCH B-2608-A
│   │   production site: Facility A
│   │   production period: Aug 2026
│   │   batch evidence: test/report references
│   │
│   │   ├── ITEM 000001 [only if business needs item identity]
│   │   └── ITEM 000002
│   │
│   └── BATCH B-2611-C
│       production site: Facility C
│       production period: Nov 2026
│
└── VARIANT HS-100-WHT-M
    colour: white
    size: M
    SKU: HSO-WHT-M

Suppose the fibre composition is genuinely identical across all variants. The brand can maintain the composition once at the appropriate common scope with evidence that covers those variants.

If the white version uses a different treatment or composition, it gets a variant-specific record.

If Facility C produces a later replenishment batch, the factory and batch evidence should not overwrite the earlier Facility A history.

If the business later decides to assign item identifiers for repair and resale, each item can inherit the product, variant and batch facts. It does not require the brand to duplicate every inherited value onto every physical-unit record.

If the future delegated act selects batch-level DPPs, the hierarchy can generate that view.

If it selects model-level behaviour, the model can aggregate or reference the relevant lower-level evidence.

If item-level identifiers become required or useful, the item layer already exists.

That is what "low regret" means in this context.

What to prepare before the textile delegated act

PREPARE

• explicit product/style and variant relationships
• a real production-batch object
• typed identifiers with clear scope
• governed existing product information
• evidence provenance
• effective dates and change history
• a mechanism for inheritance and override
• machine-readable data rather than PDF-only truth
• mappings from ecommerce, PIM, ERP and supplier systems.

KEEP FLEXIBLE

• the regulatory definition of model
• which variants share one passport
• final passport granularity
• final carrier
• final access rights
• final textile DPP fields
• whether item identifiers are mandatory, optional or unnecessary for a particular use case.

DO NOT HARD-CODE

• item-level DPP as a legal certainty
• GTIN as the universal DPP identifier
• SKU as the legal DPP level
• a speculative 2028 compliance date
• every candidate field in the May 2026 study as mandatory.

What would change this page

This page should be rechecked when any of the following occurs:

1. the textile ESPR delegated act is adopted
2. the Commission publishes a formal draft with materially clearer granularity rules
3. final textile identifier or carrier requirements are adopted
4. official access-right rules for textile passport data are set
5. a later official study materially changes the current granularity proposals.

At that point the practical hierarchy may still be useful, but the labels PREPARE, KEEP FLEXIBLE and DO NOT HARD-CODE should be tested against the adopted rules.

Direct questions

Will every textile item need its own DPP?

Not established. ESPR allows product-specific rules to choose model, batch or item level. The final textile rule has not yet made that legal choice.²

Is SKU-level the same as item-level?

No. A SKU usually represents a sellable stock configuration. Many physical items can share one SKU.

Should every size and colour have a separate DPP?

Not established. Store size and colour as explicit variant attributes now. Do not assume each combination must become a separate legal DPP.

What is a batch-level passport?

Under ESPR, batch is one of the possible DPP levels that a product-specific delegated act can select and define. For textiles, the final legal definition and application are not yet fixed.²

Should brands create item IDs now?

Only where there is a business, traceability or lifecycle reason that justifies them. Design the system so item identity can be added later. Do not create full item-level infrastructure solely on the claim that EU textile law already requires it.

Is GTIN the same as the DPP identifier?

Not universally. GTIN can be an important commercial identifier and appears in ESPR's DPP information architecture, but current law does not make it the universal DPP identifier for every product category.²

What data should be shared across variants?

Only facts that are genuinely common to those variants and supported by evidence with the right scope. Use inheritance rather than copying the same value blindly.

What should brands prepare before the textile delegated act?

Prepare identity, hierarchy, batch relationships, typed identifiers, evidence provenance, change history and machine-readable product truth. Keep the legal DPP mapping configurable.

Related ActivateDigital Knowledge

• Digital Product Passport Requirements by Product Category
• Textile Digital Product Passport Requirements (P1 canonical dossier, wire when published)
• How to Prepare for a Digital Product Passport
• Is Your Product Data Ready for a DPP?
• Model, Batch or Item Level for a Textile Passport
• Barcodes and Product Identifiers
• Passport Evidence: How We Know, and What a Blank Means

This is a regulatory information resource, not personalised legal advice. Product scope and applicable obligations should be checked against the law applying to the specific product and operator.

Sources

• European Commission, Textile apparel and the Digital Product Passport. Current sector implementation page. Indicative Q4 2027 delegated-act timing and warning that timelines may evolve.

  View official source

• Regulation (EU) 2024/1781, Ecodesign for Sustainable Products Regulation (ESPR). Especially Recital 33, Articles 9-11 and Annex III. Article 9 requires product-specific delegated acts to specify model, batch or item level and the applicable definitions.

  View official source

• Study in support of the Digital Product Passport for textiles, May 2026. European Commission Joint Research Centre / Product Bureau supporting study. See the report disclaimer and section 9.1 on granularity. The study is development evidence and does not itself establish binding textile DPP requirements.

  View official source

• European Commission, Digital Product Passport. Current implementation timeline places textiles, aluminium and tyres on the Q3-Q4 2027 sector-specific delegated-act track.

  View official source

https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en