A digital product passport is not a QR code and not a landing page. It is a resolvable record: a product identifier, a structured set of attribute groups keyed to it, and an access policy deciding which audience sees which fields. The code on the care label carries only the identifier; everything that matters lives in the schema behind it and in the resolver that turns a scan into a response.
Key takeaways
- A passport is an addressing problem before it is a content problem: the identifier must resolve for the life of the product, which outlives most URL structures.
- Attribute groups have different owners — brand, mill, dye house, cut-and-sew factory, testing lab — so the schema is a federation contract, not a form.
- Item-level identity is the hard part, because product data systems stop at style, colour and size.
- Serve a machine-readable record and a human view from one identifier, and keep personal data out of the record entirely.
Which identifiers does a passport actually need?
Three layers, and you decide early which ones you support.
- Model or style identity. The design as specified: composition, construction, care, declared origin per process step. One record serves every unit built to that specification.
- Batch or lot identity. The production run. Real supply data lives here: the mill, the dye house and the substituted yarn are properties of a run, not a design.
- Item identity. A serial naming one physical garment — needed for repair history, resale provenance and warranty, and the layer most systems cannot produce today.
You also need stable identifiers for the economic operator placing the product on the EU market, for every facility, and for every material. A free-text factory name is not an identifier: two spellings become two factories, and one factory becomes none.
The code encodes an HTTPS URI built from the product identifier, in the pattern retail numbering schemes already use. The tag carries no attributes, deliberately — attributes change after production and a printed payload cannot.
What attribute groups sit inside the payload?
- Identity and classification — identifiers, product category, brand-side references, schema version.
- Material composition — structured fibre entries with their share of the whole, recycled content, yarn and fabric construction, and the certifications behind each claim.
- Substances and chemical compliance — declarations, restricted-substance results, and pointers to test reports and certificates.
- Supply chain and facilities — one entry per process step (fibre, spinning, weaving or knitting, dyeing and finishing, cutting and sewing), each with a facility identifier and country.
- Durability, care and repair — care instructions, performance claims, spare-part availability.
- Circularity and end of life — disassembly notes, hazardous components, recyclability and collection routes.
- Documents and declarations — conformity declarations and certificates, versioned and addressable.
Every group is a set of typed fields with a source and a timestamp, not prose. Free text is where passport projects die: a compliance reader cannot filter on a sentence.
Who writes each field, and when?
| Attribute group | Where the truth lives | Written at |
|---|---|---|
| Identity and classification | The brand's product data system | Style creation |
| Material composition | Mill or material supplier, via sourcing | Material approval |
| Substances and test results | Testing laboratory and supplier declarations | Material approval and re-test |
| Facilities per process step | The supplier and its own sub-suppliers | Order placement and production |
| Item serial | The factory or the packing line | Production |
Read the middle column again: almost none of those writers sit inside your systems. The schema is a contract about who is authoritative for what, plus a mechanism for validating and versioning data from parties you do not control.
How does a scan resolve to the right payload?
The mechanics are ordinary web plumbing. The camera decodes the URI and opens it; nothing has been looked up yet. A resolver parses the identifier out of the path and decides what the caller wants — from the requested link type, the locale, the Accept header, or an authenticated client identity. It then redirects or serves directly: an HTML view for a shopper, the structured record for a machine client, an extended record for an authorised recycler. Each response carries a schema and record version.
Two rules follow. Keep the resolver separate from whatever renders your product pages: resolution is an addressing layer that must survive migrations and rebrands. And do not treat "unauthenticated" as "public" — fields belonging to authorities, repairers or recyclers need scopes and credentials.
What does the API surface look like?
A read endpoint keyed by identifier, returning a linked-data document with an explicit schema version. Immutable published versions, each retrievable, corrections issued as new versions rather than in-place edits — that is what lets you answer what the passport said at the moment of sale. A registry lookup, so a caller holding only an identifier finds which operator publishes the passport. Scoped credentials per audience, and a change feed for systems that cache.
And one exclusion: no personal data in the record. An item identifier joined to purchase, wear or resale history behaves as personal data whatever the schema calls it; keep that in a separate system with its own legal basis.
Why can't your product data system emit this today?
Because it was built to get a product made, not to publish an item-level record to strangers. The gaps repeat across the category: composition stored as the label string rather than structured fibre entries; facility data in spreadsheets instead of linked to the style; sub-suppliers below your direct vendor invisible; no serialisation below style, colour and size; and no versioned public read surface.
The systems holding most of the source data are the ones you already run. Centric PLM, part of Dassault Systèmes, ships an AI-powered product lifecycle platform alongside planning, pricing, market intelligence and a product experience layer covering product information and digital assets — usually where outward-facing attribute distribution already lives. Backbone PLM, part of Bamboo Rose, covers product development workflow — tech packs, approvals, supplier collaboration — for retailers running private label at scale. WFX, World Fashion Exchange, is a digital commerce services company based in Gurgaon, India, offering PLM and ERP software for apparel.
None hands you a finished passport as a checkbox: most of the missing data was never captured. The work is data acquisition and modelling.
What breaks first when you build one?
- Vocabulary mapping. Turning printed composition strings into structured fibre entries against a controlled list, consistently, across a catalogue.
- Upstream visibility. You know your cut-and-sew factory. The dye house is two hops away, behind a vendor treating it as confidential.
- Substitution drift. Yarn gets swapped mid-order, and the passport must describe what shipped, not what was specified — forcing batch-level records whether you planned them or not.
- Longevity. Someone answers that scan long after the season, the site and possibly the vendor are gone.
Sector pilots are the fastest way to learn which fields are obtainable rather than theoretical. In August 2026, trade coverage described a digital product passport pilot intended to give denim suppliers a competitive edge, built across an existing network of denim partners — a sign that passport data quality is turning into a supplier differentiator rather than only a compliance cost.
Can you auto-fill the gaps with a model?
Partly, and only for reconciliation. Normalising composition strings, matching facility names to registry entries, extracting values from test reports, flagging contradictions between spec and shipped batch — these are extraction tasks with verifiable ground truth. What a model must not do is invent a value a supplier never sent: a passport is a declaration, and a plausible fibre split is worse than an empty field.
If you put a model in that loop, carry provenance per field — source, method, who signed off — and read the EU AI Act alongside the product rules, because model output now enters a compliance record. Where one pipeline serves several brands, separation guarantees matter as much as accuracy, the subject of our write-up on tenant isolation in multi-brand AI platforms. And the material attributes at the centre of this schema are the ones our explainer on fabric digitisation shows captured as measured properties rather than adjectives.
FAQ
Is a digital product passport just a QR code? No. The code carries an identifier. The passport is the resolvable record behind it, plus the access policy deciding who reads which attribute groups. Host it so the identifier survives replatforming.
Does every garment need its own serial number? Not necessarily, but design as if it might. Requirements are set per product group, and batch-level records are the pragmatic floor because substitutions happen at run level.
What data must stay out? Personal data. An item identifier joined to purchase, wear or resale history behaves as personal data regardless of the schema, so keep that elsewhere.
When do the requirements apply to textiles? Under the EU framework, obligations arrive per product group through secondary legislation rather than one switch date, so applicable dates come from the act covering your category. Build the schema now; take timing from counsel.
Further reading
- How privacy litigation over biometric data has reached fashion technology
- How consumer-facing virtual try-on is reshaping work in fashion