How to Create a Digital Product Passport

Most first passports fail for the same reason: the team starts with the visible part. A QR code is chosen, a landing page is designed, and only then does anyone ask what the code should resolve to, who is allowed to see what, and where the material data will come from.

This walkthrough runs in the order that avoids that. Each step depends on the one before it, and the carrier — the part everyone pictures first — comes last.

Step 1: Assign a resolvable identity

Before anything else, decide what a passport is about. Three levels are possible, and they are not interchangeable.

Choose the coarsest level that satisfies your obligations, because granularity is expensive and hard to reverse. But note that batteries above 2 kWh under 規則(EU)2023/1542 require item level, and state of health cannot be recorded at batch level.

The identifier should be resolvable, which in practice means GS1 Digital Link. A plain internal SKU is not enough: the point is that scanning the product produces a web request, not a string a human has to look up.

Step 2: Define the data model

The decision that shapes everything downstream is whether you model against a regulation or against the product.

Modelling against a regulation means your schema mirrors the fields the ESPR(EU)2024/1781 delegated act asks for. It is faster initially, and it means the next regulation — or the next delegated act — is a rewrite.

Modelling against the product means your schema describes what the product is: composition, origin, impacts, durability, end-of-life. Each regulation then becomes a mapping over that model. The first regulation costs more; every subsequent one costs far less.

• Use standard vocabularies where they exist, so data is portable between systems and vendors.
• Record units and methodology alongside every figure. "61.4" is not a carbon footprint; "61.4 kg CO2e per kWh, ISO 14040" is.
• Model provenance as a first-class field. Who asserted this, when, and on what basis — not just the value.
• Represent absence explicitly. A missing recycled-content figure is different from zero recycled content, and conflating them creates false compliance.

Step 3: Collect and validate the data

This is where programmes actually spend their time. Expect the same field to arrive under four different names, in three unit systems, from suppliers with varying willingness to answer at all.

Two practices make the difference. First, deterministic mapping before human review: alias tables resolve the obvious cases automatically, so people only see the genuinely ambiguous ones. Second, record gaps as gaps rather than filling them with plausible defaults — a fabricated figure is worse than an acknowledged absence, because it is indistinguishable from a real one later.

Step 4: Sign the claims

A passport that asserts "38% recycled aluminium" on your own authority is a marketing claim. The same assertion, signed by the smelter that measured it and independently verifiable, is evidence.

Issue material claims as W3C Verifiable Credentials, signed by the party that actually knows the fact. A regulator or customer can then check the signature without trusting your platform, which is the entire point — it removes you as a required intermediary.

Not everything needs signing. Care instructions do not. Anything a regulator might challenge, or that carries commercial value if believed, does.

Step 5: Attach the carrier

Only now does the physical carrier matter, and by this point the decision is largely mechanical: it encodes the identity from step one.

Because the carrier only encodes identity, changing it later is cheap. A product can carry a QR code today and gain an NFC tag next year without touching the passport itself — which is precisely the benefit of deciding it last.

Step 6: Publish the resolver

The resolver turns a scan into the right response for the right audience. One identity, five views: a consumer gets care and repair information with no login; a recycler proves a role credential and gets disassembly and hazard data; a regulator gets the full evidence chain.

Two requirements are easy to underestimate. Restricted fields must be withheld by the server based on a verified role, and an unauthorised request should be refused outright rather than silently returning a trimmed record — otherwise a caller cannot distinguish "no data" from "not permitted". And the resolver must keep working for the product lifetime, which for a battery or a building product means a decade or more.

Do one before you do a thousand

Take a single product line through all six steps with real supplier data. It will take longer than expected and will surface problems no design review would have found — a supplier who will not respond, a unit mismatch nobody noticed, a claim nobody can actually evidence.

That is the point. Discovering those at one-product scale costs weeks. Discovering them at catalogue scale costs the programme.