Digital Product Passport Software Problems: The 7 That Stall a Programme in Year Two, and How to Avoid Them

Why does a passport programme get scoped as a publishing project?

Because the deliverable everyone can picture is the page a consumer sees after scanning a code. So the brief becomes a product page with sustainability fields, a code generator and a content management screen, and a team ships it in ten weeks. Then somebody has to fill the fields, and the programme meets the actual problem: the facts belong to companies you do not contract with, and nothing in what you built helps you get them.

The real shape of the work is a collection system with a publishing surface attached, not the other way round. Your compliance lead opens a readiness grid with three hundred styles down the side and fibre composition, origin at each processing stage, recycled content, chemical evidence, repair instructions and end of life routing across the top. Most cells are empty. The filled ones came from a questionnaire answered in a hurry by a sourcing agent and were never checked against a document.

The fix is to specify the claim before the page. A claim has a subject, an asserting party, a source document, a validity window, a scope and a version. Every published field must resolve back through that chain to whoever asserted it. A team that draws a products table with a sustainability column has built a catalogue and will rebuild the whole thing in year two, once someone asks who said this and on what evidence.

What goes wrong with the bill of materials and supplier data you migrate in?

The passport asserts facts about a physical object. Your systems hold commercial documents about a purchase order. The migration is where that gap becomes visible, and it usually becomes visible in public.

The first problem is that the bill of materials in your product lifecycle management system describes the intended construction rather than what the factory actually cut. Substitutions happen at the mill and at the vendor, sometimes with approval and sometimes without, and the record of them lives in an email thread. If you publish from the intended bill of materials, you publish a mismatch to the open internet at scale.

The second is unit of measure and vocabulary. The same material appears as recycled polyester, rPET and post consumer PET across three suppliers, with weights in different units. Without a controlled vocabulary and a mapping layer with a named owner, your composition figures are not comparable across styles and cannot be aggregated for reporting.

The third is evidence with no expiry. Certificates and test reports migrate in as attachments with no structured issue date, scope or issuing body, so nothing can tell you which ones have lapsed. The fix is to extract those fields on ingest, store them as structured attributes on the claim, and refuse to publish a field whose supporting evidence is expired or out of scope. Machine extraction makes this affordable, because nobody reads four thousand documents a season by hand.

Why do the product lifecycle, resource planning and label vendor integrations break after launch?

Reading a bill of materials out of Centric or PTC FlexPLM is a different problem from reading one out of a spreadsheet, and both are different from confirming applied serials back from a label vendor. Teams tend to scope the first, assume the second and forget the third.

The label vendor path is where programmes stall. If a code is going onto a care label or a carton, somebody has to allocate a serial range to a production order, print it, apply it, and confirm back what was actually applied. Printing happens at a vendor site, on their equipment, on their schedule, and the confirmation file is whatever their system can produce. Reconciliation gaps appear immediately: ranges allocated and never used, ranges used twice, units shipped with codes that were never activated in your resolver. A scanned code that resolves to nothing is worse than no code at all.

The other recurring break is the enterprise resource planning (ERP) join. Passport records need to know which units shipped to which market, because disclosure and language obligations follow the market of sale. That link is often assumed and rarely modelled, and it is discovered late, usually when a second market goes live.

Three concrete fixes: activate a serial in the resolver only on confirmed application, never on allocation; treat every vendor confirmation file as an untrusted input with schema validation and an alert on mismatch; and build the market of sale link in phase one even if you are launching into a single market.

What happens when disclosure, language and retention rules are not fully covered?

A passport view is 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. Build one public page and you either expose commercially sensitive supply chain detail or you fail to give an authority what it can require. Build four hand maintained pages and they will disagree within a quarter.

The obligations themselves come from the Ecodesign for Sustainable Products Regulation, delivered through delegated acts by product group, with the EU Battery Regulation carrying its own passport obligation for the categories it names. Have your exact field set, scope and dates confirmed by regulatory counsel rather than by a vendor deck, because delegated acts move.

What the system must handle regardless:

• Role scoped views computed from one record, so the consumer view, the repairer view, the recycler view and the authority view can never drift apart.
• Language by market of sale, which multiplies views rather than adding a field, and needs a translation workflow with version control.
• Retention beyond the product life, since the record must stay resolvable for a defined period after the last unit is placed on the market. The resolver has to outlive the campaign, the season and possibly the agency that built it.
• Versioned corrections with reasons and timestamps, so a claim asserted in March and corrected in September are both retrievable. Store the record as an append only event log and this is a query rather than an archaeology project.

Should you build custom or configure an existing platform?

Buy, and we say this on calls regularly, if you have under roughly two hundred active styles, one European market, a supply chain short enough that you can phone the mill, and no serialisation in production. EON will get you compliant faster and cheaper than a build, and the platform fee costs less than the discovery phase of a custom project. TrusTrace is a serious answer if your central problem is supply chain data collection and chain of custody documents, which it was built for. Circularise suits material flow and mass balance work in chemicals, plastics and batteries better than a forty vendor apparel base.

The trade with a platform is namespace and data model. Your product identity lives inside someone else's system, and changing your mind later means re-tagging goods already in the market.

Build when two or more of these are true: your passport fields have to be assembled from tier two and tier three suppliers you do not contract with, you already serialise units for another reason so half the identity work exists, you sell across categories that will fall under different delegated acts, your product data of record sits in a system the business will not replace, or the passport is commercially interesting beyond compliance for resale, repair or authentication. In that last case the record becomes a product feature and renting it is a strange choice.

How do hidden costs get into the quote?

In Digital Heroes delivery experience 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. The full programme with unit level serialisation, factory confirmation, integration and post sale write access runs $300,000 to $750,000 across 9 to 18 months. The overruns come from five places.

• Supplier tier depth. Reaching tier three is a change management programme with software attached, and the software is the cheap part.
• Serialisation, especially where vendors print. Every label vendor is a separate confirmation format and a separate reconciliation story.
• Category count, because each product group brings its own field set, its own vocabulary and its own evidence types.
• Market count, since language and disclosure rules multiply views and translation workflows.
• Existing data quality, which nobody budgets for. If the bill of materials does not match what was cut, the passport publishes that mismatch publicly, and cleaning it up is a business exercise rather than a development task.

What holds the number down is discipline about phase one: one category, one market, batch level identity, and your top vendors by volume rather than all of them.

What separates a passport build that works from one that stalls?

Three things decide it. The first is request design. Suppliers answer short tasks tied to one purchase order and one claim. They do not answer ninety field questionnaires, or rather they answer one honestly and then copy it forward forever, which produces numbers that sound right and evidence that does not exist.

The second is identity granularity chosen deliberately. Batch level is a legitimate first step where unit level is not yet required, but only if the record model is unit ready from the beginning, so moving later is a data migration rather than a rebuild.

The third is who owns the resolver. It must sit on your domain, in your cloud accounts, with your team able to keep it up for years after the last unit was sold. It should be a small, boring, extremely available service with one job, never coupled to the system that authors the data. Design the third party write path early even if you keep it closed in year one, because repairers, resale platforms and recyclers will want to write to the record and a schema migration to accommodate them is a bad way to spend year three. At Digital Heroes the client owns the code, the accounts and the domain from the first commit, and on a record that must outlive the agency relationship that is not a preference, it is a requirement.