Item-Level vs Batch/Lot-Level Serialization under the EU ESPR

1 The granularity question

The Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781, has been in force since 18 July 2024. It does not itself list the data each passport must carry. It establishes a framework and delegates the specifics to product-group delegated acts. The first ESPR Working Plan, adopted on 16 April 2025, sequences those acts: iron and steel (indicative 2026), textiles and apparel, tyres and aluminium (2027), furniture (2028) and mattresses (2029). Batteries are governed in parallel by the Battery Regulation (EU) 2023/1542, whose battery passport applies from 18 February 2027.

Each delegated act answers one question that determines every downstream engineering decision: at what level of granularity does the passport exist? The framework recognises three levels. A passport can describe a model, a production batch or lot, or a single serialized item. Granularity is not a stylistic preference. It is fixed by the delegated act for the product group, and it governs how identifiers are minted, how data carriers are produced, how updates propagate, and how long each record must remain resolvable.

Two patterns dominate real deployments. High-value, lifecycle-tracked goods such as electronics and batteries move toward item-level serialization, where the unit is the unit of accountability. High-volume goods such as textiles and apparel move toward batch or lot-level passports, where serializing every garment is neither proportionate nor practical. The rest of this paper breaks down both, and shows how one platform serves them without compromise.

2 One GTIN, two carriers

Whatever the granularity, the passport is reached through a data carrier: a QR code or comparable scannable identifier, encoded as a GS1 Digital Link URI. This is the standard the DPP ecosystem is converging on, because the same identifier resolves for a human scanning a phone and for a customs system reading the structured record. The difference between the two serialization models comes down to a single GS1 Application Identifier in that URI.

3 Item-level serialization: electronics and batteries

Item-level means every physical unit carries its own identifier and resolves to its own passport. It is the right model where the obligations attach to the individual product over its life: an EV or industrial battery whose state of health, charge cycles and second-life status change after sale, or an electronic device tracked through repair, refurbishment and recycling. The EU battery passport, mandatory from February 2027 for the relevant categories, is item-level in character for exactly this reason.

In DPPespr, item-level issuance follows a master-and-serial structure. A single master passport row holds the shared product data, and each unit is represented by a lightweight serial record bound to it. The serial QR resolves through the GS1 Digital Link path /01/{gtin}/21/{serial}. Serials are enforced as unique within a GTIN, which is the GS1 requirement, and each issued serial counts as one passport against the account allowance, enforced at the moment of generation rather than after the fact.

Why this matters technically

Item-level data carries a heavier operational load. Identifiers must be generated and printed in volume, each unit's record must remain individually resolvable for the full retention period, and lifecycle events have to be attributed to the correct serial. The payoff is precision: a recall can target the affected units rather than a whole catalogue, provenance is established per unit, and downstream actors can read and append events against a specific item rather than a generic model.

4 Batch/lot-level serialization: textiles and apparel

Batch or lot-level means one passport describes a production run, and every unit in that run shares it. For textiles and apparel this is the proportionate model. A run of tens of thousands of identical garments shares the same fibre composition, the same chemical declarations, the same country of origin and the same care and end-of-life guidance. Serializing each garment would multiply cost and data volume with no compliance benefit, because the information that the regulation cares about is identical across the run.

In DPPespr the batch passport resolves through /01/{gtin}/10/{lot}, or the equivalent human-readable /gtin/{gtin}/lot/{batch} path. The lot number is the unit of accountability. The textiles delegated act, expected in 2027, is anticipated to require fibre composition, chemical and substances-of-concern information, durability data and end-of-life instructions: all attributes that live naturally at the batch level.

Why this matters technically

Batch-level keeps the identifier count and the record count proportionate to production reality, so issuance is fast and storage is lean. The trade-off is resolution: accountability stops at the lot. Where a delegated act later demands finer tracing, the same GTIN can carry both a lot and a serial in one URI (/01/{gtin}/10/{lot}/21/{serial}), so a batch-level programme can graduate to item-level without re-platforming or re-labelling the identifier scheme.

5 The two models at a glance

The choice is set by the delegated act, not by preference. The table below summarises how the two models differ in practice.

6 Issuing at scale: the asynchronous bulk API

Item-level programmes can mean tens of thousands of identifiers per production run, and a synchronous request that tried to mint and render them in one call would time out and tie up the live service. DPPespr issues in volume through an asynchronous job model, so a large request returns immediately and the work proceeds in the background under controlled concurrency.

1. Submit. A bulk request is posted to the issuance endpoint (POST /api/v1/passports/bulk-async). The call validates the payload, enqueues the work, and returns a job identifier without blocking.
2. Queue and claim. Background workers claim jobs from the queue one at a time using row-level locking (FOR UPDATE SKIP LOCKED), so concurrent workers never collide on the same job and a failed worker cannot strand one.
3. Process under limits. Work runs at bounded concurrency, streams output to disk rather than holding it in memory, and yields to the event loop between batches so the live site stays responsive throughout.
4. Poll for status. The client polls the job (GET /api/v1/passports/bulk-jobs/:id) for progress and completion, rather than holding a connection open.
5. Collect. On completion the result, such as a QR pack archive, is retrieved from its download endpoint and expires on a fixed retention window so storage does not accumulate.

The same pattern backs serialized QR generation, where a single master passport fans out into a pack of unit-level codes. Because allowance is enforced at generation time, a bulk job cannot quietly exceed an account's passport entitlement.

7 Long-term data validity: XRP Ledger anchoring

A Digital Product Passport is only as trustworthy as the assurance that its data has not been altered after the fact. DPPespr establishes that assurance with cryptographic anchoring to the XRP Ledger, which produces an independent, tamper-evident timestamp for passport data. The mechanism is deliberately simple and privacy-preserving: no personal or commercial data ever leaves the platform, only a cryptographic digest.

1. Hash. Each passport's core claims (GTIN, lot, name, country of origin, category and fibre composition) are normalised into a canonical form and reduced to a SHA-256 digest. Identical content always yields the same 64-character hash, so any later change to the data produces a different hash.
2. Batch. On a recurring cycle, the hashes of all passports changed since the last run are combined into a single Merkle tree. Each passport keeps the proof path needed to recompute the tree's root.
3. Anchor. Only the single Merkle root is written to the XRP Ledger, carried in the memo field of a fee-only transaction that transfers no value. One transaction makes an entire cycle of passports tamper-evident, and the ledger records the time it was confirmed.
4. Verify. A public verification endpoint (GET /api/v1/passports/:id/notary) recomputes the passport's hash from its current data, re-walks its Merkle proof to the anchored root, and confirms the transaction on the ledger. It reports verified only when the data matches, the proof is valid, and the anchor is confirmed.

8 Compliance posture

The granularity decision is made for you by the delegated act that governs your product group. The engineering task is to honour it without locking yourself out of the next one. DPPespr resolves item-level and batch/lot-level passports through one GS1 Digital Link scheme, issues either at production volume through an asynchronous job model, and anchors both to a public ledger for tamper-evident integrity. Whether the regulation asks you to account for a garment by its lot or a battery by its serial, the identifier, the carrier and the proof of integrity are already in place.