Digital Product Passport Software: How Do You Publish Item Level Claims When the Data Sits With Your Supplier's Supplier?

Why the passport request lands on someone who has no data

A compliance director at an apparel brand opens the readiness grid her team built for the autumn range. Three hundred and forty styles down the left. Across the top: fibre composition, country of origin at each processing stage, recycled content, chemical compliance evidence, repair instructions, end of life routing. Most of the grid is empty. The cells that are filled came from a supplier questionnaire sent last spring, answered by a sourcing agent in a hurry, and never checked against a document. The brand does not buy yarn. It buys finished garments from 40 vendors, who buy fabric from mills the brand has never spoken to, who buy yarn from spinners nobody in the building can name.

That is the honest starting position for nearly every passport programme we are asked to cost. The regulation asks for verifiable facts about a physical object. Your systems hold commercial documents about a purchase order. Between the two sit three or four supplier tiers, a testing lab and a customs broker, none of whom work for you. The Ecodesign for Sustainable Products Regulation came into force in 2024 and delivers passport requirements through delegated acts by product group, with textiles named as an early priority. The EU Battery Regulation carries its own battery passport obligation for the categories it names from February 2027. Have your exact scope and dates confirmed by regulatory counsel, because delegated acts move and a blog post does not.

What does not move is the shape of the work: a durable identifier carried on the product, a record behind that identifier, a collection process that pulls facts out of companies who are not on your systems, and a public view that renders correctly in every market you sell into. Each of those is a build decision. The sequencing between them decides whether the programme lands or stalls in year two.

Problem 1: the facts belong to suppliers with no reason to hand them over

Your vendor is a garment maker on a thin margin with a messaging app and a cutting room. You are asking him to chase his fabric mill for a recycled content claim backed by a transaction certificate, and to chase that mill's spinner for fibre origin. He gains nothing from the work and loses a day. So he sends a number that sounds right. This is the exact point where passport programmes fail, and no dashboard fixes it.

TrusTrace and Circularise are both real answers to parts of this. TrusTrace is built around supply chain data collection and chain of custody documents and does that competently. Circularise approaches it from material flow and mass balance, which suits chemicals, plastics and batteries better than a 40 vendor apparel base. What neither can do for you is own the join between a purchase order line, the specific fabric lot cut against it, the mill's lab report and the units that shipped. That join lives across your PLM, your ERP and your vendor's cutting room, and it is precisely what a passport asserts. A platform that stores documents against a supplier is not the same object as a record that stores evidence against a product instance.

What a custom build does: model evidence as a claim with a subject, a source, a document, a validity window and a confidence state. Every field on the passport carries a provenance chain back to the party who asserted it. Requests go out to suppliers as short tasks tied to one purchase order and one claim, not as a 90 field questionnaire, because a 90 field questionnaire gets one honest pass and then autocomplete forever. Document extraction earns its place here: certificates and lab reports arrive as PDFs in a hundred layouts, and a model reads the certificate number, the scope, the issuing body and the expiry, then flags the ones that lapsed or that cover a scope your claim does not match. Nobody on your team is reading 4,000 PDFs a season. A model reads all of them and hands you the 60 that are wrong.

Problem 2: the identifier, and whether you can afford unit level

The passport resolves from a code on the product, so you must decide per category whether that code identifies a model, a batch or a single unit. Unit level is where the rules are heading for categories where repair, resale and recycling matter, and it is also where your factory floor starts to argue. A unique code on a care label means serial generation, allocation to a production order, and reconciliation of what was actually printed and applied. That is a manufacturing execution problem sitting inside a compliance project, and it is usually the part that slips.

EON is genuinely strong on this and deserves a serious look if you are willing to adopt someone else's identity infrastructure and consumer experience wholesale. The trade is that your product identity then lives in their namespace and their data model, and changing your mind later means re-tagging goods already in the market. Protokol will build around you, but you are buying a project either way. GS1 Digital Link is the sensible public standard for making a code resolvable, and a vendor who cannot explain how they handle it has told you something useful.

What a custom build does: keep the identifier and the resolver on your own domain from day one. Serial ranges are allocated to production orders, printed by the factory or your label vendor, confirmed back as applied, and only then activated in the resolver. Batch level identity is a legitimate first step where unit level is not yet required, provided the record model is unit ready so you are not rebuilding it two years later. The resolver itself should be small, boring and extremely available: one job, very high read volume, never coupled to the system that authors the data.

Problem 3: the public view is a legal artefact, not a marketing page

A passport view gets read by a consumer, a repairer, a recycler, a customs officer and a market surveillance authority, and those audiences are entitled to different levels of detail. Some fields are public, some are restricted to authorised parties, some are commercially sensitive and must never surface even though they sit in the same record. Language obligations follow the market of sale. The record must stay available for a defined period after the last unit is placed on the market, which means the resolver has to outlive the product, the campaign and possibly the agency that built the site.

What a custom build does: role scoped views computed from one record rather than four hand maintained copies. Versioning is not optional, because a claim asserted in March and corrected in September must both be retrievable with timestamps and a stated reason. Store the record as an append only event log. When an authority asks what you published on a given date, you answer in a minute instead of reconstructing it out of email threads.

Problem 4: the record keeps changing after the product ships

Repairs, spare part availability, resale events, warranty claims and eventual recycling all write to the passport after the sale. A programme that treats the passport as a document generated at the end of production will be built twice. Resale platforms want to read it. Independent repairers want to write to it. Recyclers want material composition in machine readable form, not a paragraph of prose.

Design the write path early even if you keep it closed in year one. That means an authenticated third party API, a permissions model per party type, and an event store that can absorb a repair record from a partner you have not signed yet without a schema migration.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape of passport work. A first release covering identifier assignment, the supplier claim collection workflow, the record store and one public market view runs $110,000 to $240,000 and ships in 14 to 20 weeks. That is a live resolver serving real product data, not a pilot on a slide. The full programme, adding unit level serialisation with factory confirmation, PLM and ERP integration, evidence extraction, restricted party views and post sale write access, runs $300,000 to $750,000 phased across 9 to 18 months.

What drives the number up: the number of supplier tiers you must reach, because tier 3 collection is a change management programme with software attached. Unit level serialisation, especially where labels are printed by vendors rather than by you. Category count, since each product group brings its own field set. Market count, because language and disclosure rules multiply views. And existing PLM quality, which nobody budgets for: if the bill of materials in your PLM does not match what the factory actually cut, the passport publishes that mismatch to the public internet. What keeps the number down: one category, one market, batch level identity, and your top vendors by volume rather than all of them.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you have under roughly 200 active styles, a supply chain short enough that you can phone the mill, no serialisation in production and a single EU market. EON or TrusTrace will get you compliant faster and cheaper than a build, and the platform fee costs less than the discovery phase of a custom project. That is a real answer and we give it regularly.

Build when two or more of these are true. Your passport fields must be assembled from tier 2 and tier 3 suppliers you have no contract with. You already serialise units for another reason, so half the identity work exists and a platform would duplicate it. You sell across several categories that will fall under different delegated acts, so one vendor's data model will fit a single category and fight the rest. Your product data of record sits in a PLM or ERP the business will not replace. Or the passport is commercially interesting beyond compliance, meaning resale, repair or authentication, in which case the record becomes a product feature and you should not rent it.

How to choose a developer for passport work

Ask them to model a claim on a whiteboard before you sign anything. A team that has done this draws claim, subject, evidence document, asserting party, validity window and version, and they will explain why the asserting party matters more than the value. A team that draws a products table with a sustainability column has built a catalogue and is about to learn regulatory data modelling on your budget.

Ask how the resolver stays up and whose domain it sits on. If the answer places your product identity on the developer's infrastructure, walk. Ask what happens when a claim is corrected after 40,000 units are already in the market, and listen for versioning rather than an edit form.

Ask what they have genuinely integrated. Reading a bill of materials out of Centric or PTC FlexPLM is a different problem from reading it out of a spreadsheet. Confirming applied serials back from a label vendor is a different problem again. Ask for the named system and the named document type instead of a general claim of integration experience.

Ask who owns the code, the repository and the cloud accounts, and get it in writing before kickoff. A passport record has to outlive your agency relationship by years. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from anyone who hedges on that.