Why we built Junction around a live record

Every product makes a bet about how its market will behave. Ours is that the digital product passport (DPP) will be treated as a document to submit, and that this will turn out to be the expensive way to do it.

Worth explaining the reasoning, because it determines what the product does and does not do.

The bet

Two facts sit underneath it.

The economic operator has to maintain data accuracy throughout the product's lifecycle. That duty does not end at launch; it runs for as long as the product exists on the market, and the passport is meant to serve repairers and recyclers long after the sale.

And products change constantly. Suppliers are replaced, materials are reformulated, facilities move, certifications lapse. None of those events announce themselves to a compliance system.

Put the two together and a passport assembled once is not merely incomplete. It drifts out of accuracy quietly, while everyone believes the task is finished. An incorrect public claim nobody knows is incorrect is worse than a missing one, particularly given that inaccurate data carries both regulatory exposure and consumer compensation risk, as covered in DPP penalties.

What follows from it

If the record has to stay current, then it cannot be a separate artefact maintained alongside your product data. It has to be generated from the source and updated as the source changes.

So Junction keeps the product record at the source and updates it as the product changes. Filing the passport becomes a step in a process rather than a project with a deadline.

Three consequences we accepted deliberately.

Setup is more work than generating a file. Connecting to where product and supplier data actually lives is harder than exporting a spreadsheet once. We think that cost is paid once and the alternative is paid every year.

The value shows up in year two. A live record is not obviously better than a generated file on the day you launch. It is obviously better the first time a supplier changes.

It only helps if the data underneath is real. No system converts unevidenced supplier claims into evidence. The supplier work described in the readiness checklist is yours, and any vendor suggesting otherwise is selling something that will fail an audit.

The second thing the code does

The other design decision worth naming: we bind authenticity and the passport into one code per product.

The regulation does not require this. It requires a carrier that reaches a record. But a code anyone can photograph and reprint proves nothing about the item it is attached to, which means good sustainability data can end up attached to a product that is not yours.

Most passport systems treat the scan as a way to reach data. We treat it as a way to check that the item is genuine and reach its data in the same action. Interestingly, the CIRPASS-2 reference architecture has no building block for consumer-facing authenticity verification at all, which we note as an observation about that model's scope rather than a claim about anyone else's product.

What this is not

It is not a claim that everyone needs the live version on day one. A company with a stable product range and one delegated act ahead of it may reasonably start simpler.

It is a statement about where the cost lands. The file approach is cheaper to start and more expensive to keep, and the keeping runs for the life of every product you sell.

Sources

• European Commission, *Digital Product Passport: FAQ*, January 2026 update, question 3 on the
• operator's lifecycle data accuracy duty, question 30 on consumer compensation rights.
• CIRPASS-2, *D4.1 Reference Architecture*, version 1.1, 9 June 2026.