Digital product passports start with ownership of the data

A passport identifies a product and connects to information about it. That requires unique, stable identifiers at more than one level — the product model or type, the individual item where item-level identification is required, and the batch or production lot that links a specific item to the conditions under which it was made.

Getting this wrong is expensive later. If a product identifier changes when a component supplier changes, or if the same identifier is reused across genuinely different specifications, the history attached to it becomes unreliable. The identifier structure needs to reflect how the business actually distinguishes products, and it needs to remain stable across design revisions.

Where item-level identification is required, the physical marking and the data record must be designed together. A marking that can be applied in production but not read at end of life serves only half the purpose.

The substance of a passport is the material and component information behind the product. That information arrives from suppliers, and supplier evidence is where most readiness gaps appear — not because suppliers are unwilling, but because the specific data required is often not part of what they currently provide.

The practical starting point is a bill of materials structured so that each significant component and material can carry the attributes that will be required of it. That means knowing which supplier provides which element, what evidence they hold, and what format it is in.

Where supplier data is not yet available, the useful step is a gap register: which elements lack evidence, which supplier holds it, and what the route to obtaining it is. This is more valuable than a platform selection, because it identifies the critical path — and the critical path usually runs through suppliers, not through software.

Product data changes. A formulation is adjusted, a supplier is changed, a material specification is revised. Without version control, a passport describes a product that no longer exists, and there is no way to establish what was true when a particular unit was made.

Version control has two requirements. Each change must create a new version rather than overwriting, and each version must be linkable to the units produced while it was current. That second requirement is what makes it possible to answer, later, what a specific item contains.

Access rights are the second governance question. Different parties need different levels of access: authorities, supply chain partners, customers, repairers and recyclers. Designing access as a property of the data, rather than as an afterthought, avoids a common pattern in which access is granted broadly because restricting it is difficult.

Both version control and access rights are decisions about ownership. They cannot be delegated to a platform, because the platform implements whatever policy it is given. If no policy exists, the platform will implement an implicit one.

The sequence that avoids wasted investment is: establish product scope, establish the data model, establish ownership and change triggers, close the evidentiary gaps with suppliers, and only then evaluate platforms against a defined requirement.

A manufacturer that reaches platform evaluation without a data model will find every vendor credible, because there is no requirement to evaluate against. A manufacturer that arrives with a defined data model, a gap register and a set of access rules can ask precise questions — and can tell which vendors understand the problem.