A practical guide to testing whether a platform can manage real product data, regulatory change and supply chain evidence

Digital Product Passport demonstrations are often visually convincing. Scan a QR code and a polished page appears, complete with product details, sustainability claims and recycling information. That proves that information can be published. It does not prove that the solution can operate as part of a regulated, multi-company product information system.

The difficult work happens before and after the page is displayed. Data must be obtained from internal systems and suppliers, interpreted against changing requirements, checked, evidenced, protected, updated and exchanged with other systems. A credible evaluation should therefore begin with the data and its lifecycle, not the appearance of the finished passport.

This matters because the Ecodesign for Sustainable Products Regulation establishes a common framework, while product-specific delegated acts determine much of the information required for individual product groups. Organisations need a solution that can support decisions and pilots now without pretending that every future data requirement or infrastructure component has already been settled.

Start with the operating problem

A passport is the published result of a wider process. The responsible economic operator must assemble information that may sit in ERP, PLM, formulation, regulatory and document-management systems. Some values will come from suppliers or laboratories. Others may be calculated, inferred from product structures or supported by certificates and declarations.

This is why a comparison based mainly on templates, QR codes and consumer pages is weak. Most providers can produce an attractive representation from a complete sample dataset. The useful question is what happens when the source data is fragmented, commercially sensitive, inconsistent or incomplete.

Test how the solution acquires and understands data

Ask the provider to begin with imperfect source material: a product record, an SDS, a supplier spreadsheet and a declaration that uses different terminology or units. Then ask them to create the passport in front of you.

A serious solution should be able to show where each value came from, how fields are mapped to a defined data model, how units and identifiers are normalised, and which gaps still require human action. If artificial intelligence is used to extract or map data, the provider should also show the original source, the proposed interpretation and the approval step. Automation can reduce effort, but it does not transfer accountability from the economic operator to the algorithm.

Separate regulatory requirements from design choices

DPP requirements will not be identical across sectors. Product-specific rules will define the relevant data, granularity and access conditions. Standards and common system components will continue to develop alongside them.

A platform should therefore distinguish between an enacted requirement, a requirement expected from a draft or standardisation programme, and a configuration chosen by the customer. Ask the provider to identify those categories within the solution. A fixed form that happens to resemble today's expectations may become expensive to replace. A completely unstructured database creates a different problem: it cannot demonstrate that the required information is present or valid.

The better approach is controlled flexibility. The data model, validation rules and vocabularies should be versioned and configurable, while published passports remain tied to the rules that applied when they were issued.

Demand evidence and provenance

A populated field is not the same as a substantiated claim. If a passport reports recycled content, the evaluator should be able to identify the supplier or calculation that provided the value, the applicable product or batch, the supporting evidence, who approved it and when it was last reviewed.

This distinction becomes especially important when data has passed through several organisations. A downstream manufacturer may receive a declaration rather than the supplier's confidential formulation. The passport system must preserve the origin, scope and status of that declaration without implying that the downstream company has independently verified information it has not seen.

Ask the provider to click from a published value back to its evidence and audit history. Then ask them to replace the evidence, withdraw an approval or receive a contradictory supplier submission. The way the system handles those events says more about its credibility than the initial publication does.

Test change rather than initial publication

Products do not remain static. Formulations change, suppliers change, classifications are updated, certificates expire and repairs or refurbishment may add new lifecycle information. A DPP solution must decide which existing passports are affected and whether the change applies at model, batch or individual-item level.

A useful demonstration would change one supplier or material in a product and show the consequences. Which records become out of date? Is publication blocked pending review? Does the new information apply only to future batches? Can a user still retrieve the historically correct passport for stock already placed on the market?

This also tests whether the platform has a genuine product and material model or simply stores independent web pages. Shared information should be maintained once and inherited where appropriate, without overwriting data that is specific to a batch or item.

Examine access and confidentiality

The same passport may need to support consumers, professional operators, recyclers and public authorities. Those audiences will not necessarily have access to the same information. A credible platform must apply access decisions to the data it returns, rather than sending all information to the browser and hiding selected fields on screen.

Ask to scan the same identifier anonymously and as an authenticated business user. The provider should explain how roles are established, how access can be granted or revoked, and how restricted data can be exchanged automatically between systems. It should also be clear which elements depend on external identity, credential or European infrastructure that is still being implemented.

Check interoperability by attempting to leave

Interoperability is easy to claim when the demonstration never leaves the provider's interface. A stronger test is to request the raw machine-readable passport, import it into another tool and ask whether a different provider could interpret or host it.

The export should preserve identifiers, meanings, relationships, provenance and access metadata. JSON alone is not sufficient if the receiving system cannot determine what the fields mean. The provider should explain which open standards, vocabularies and identifier schemes it uses, and which parts are proprietary extensions.

Portability also has a commercial dimension. The customer should be able to retrieve its data, evidence and history without losing meaning if the contract ends. Long-term availability matters because many products will remain in use long after the software contract, manufacturer or original internet domain has changed.

Evaluate the upstream supply chain

Finished-product passports depend on information about materials, substances, components and packaging. A solution that begins only at the finished product leaves the customer to solve the hardest part elsewhere.

Ask how an upstream producer can provide data once and reuse it across several customers without publishing confidential information. Ask how updates propagate, how customer-specific disclosures are controlled, and how a material or component record links to downstream passports. For companies dealing with chemicals and complex formulations, this is likely to be more important than the design of the consumer-facing page.

Measure effort at realistic scale

A successful pilot with one carefully prepared product does not establish the cost of operating across thousands of products and hundreds of suppliers. The evaluation should identify what work occurs once per data model, once per product, once per supplier, once per batch and once per individual item.

This provides a more useful basis for cost than a headline price per passport. It exposes the effect of duplicated data, manual review, supplier onboarding, evidence renewal and integration maintenance. It also helps determine whether additional granularity creates business value or merely increases data volume.

A better demonstration brief

Instead of asking each provider to present its preferred demonstration, give them the same operational tasks. The following five challenges will reveal most of the differences between solutions:

Demonstration challenge	What the provider should be asked to do
Create a passport from imperfect data	Provide records from several sources with inconsistent units, missing values and at least one unsupported claim.
Change a material or supplier	Require the provider to identify affected products, preserve history and publish the change only where it applies.
Show four audience views	Use one identifier for a consumer, downstream customer, recycler and regulator, with genuinely enforced access restrictions.
Trace a claim to its evidence	Select a published value and follow it back through its calculation, declaration, source organisation, approval and review date.
Export and transfer the passport	Request a machine-readable export and the data needed for another system or provider to interpret and continue hosting it.

Warning signs during selection

Be cautious when a provider cannot show the raw data, treats every regulatory expectation as settled, describes a proprietary field list as an ontology, or relies on manual preparation that is excluded from the demonstration. Other warning signs include access control that exists only in the presentation layer, claims without retrievable evidence, and exports that lose history or meaning.

A provider should also be comfortable identifying the boundary of its current solution. Some elements of the wider European DPP system depend on product-specific legislation, standards, registries, resolvers and identity mechanisms that are still developing. Clear limitations are evidence of sound engineering judgment. Certainty where the framework remains open is not.

The decision should rest on maintainability

The best DPP solution is unlikely to be the one that produces the most impressive first scan. It will be the one that can maintain reliable product information as regulations, products and supply chains change.

That means evaluating how the platform handles incomplete data, evidence, confidentiality, granularity, revisions, interoperability and supplier participation. If a provider can demonstrate those capabilities using an imperfect real-world product, the customer has learned something meaningful. If the demonstration begins with a finished dataset and ends with a polished page, most of the delivery risk remains hidden.

Sources and further reading