How Provscope works

Provscope is not a form tool. The hard part of compliance is not drawing an interface, it is getting regular, verifiable data out of your supply chain. This page explains how that operation works, step by step.

Step 1: Scope and product tree

Everything starts with two questions: which of your products fall under which regulation, and who holds the data for each part of that product’s tree?

We map the product tree with you. This almost always shows that much of the required data sits with your first and second tier suppliers, not with you. Collection starts only once scope and data ownership are clear.

Step 2: Collecting data from suppliers

Each supplier receives a single-purpose link. They do not need to open an account, set a password or learn new software. The link opens only the fields requested from that supplier, and we track whether they have been completed.

This detail decides whether collection succeeds: your supplier will not learn software for your compliance project, and low response rates undermine the whole passport. Follow-up, reminders and closing gaps stay with us.

Step 3: Verification

Every incoming value is linked to a source: an invoice, a measurement report, a facility declaration or an accredited verifier’s report. No number stands alone in the system. Next to it, you see where it came from and which document it relies on.

Inconsistencies are flagged automatically: the same supplier reporting conflicting values for two batches, energy use that is out of proportion to production volume, or a declared value outside the typical range for the sector. A passport is not published until these flags are closed.

What you end up with is not a declaration, but a chain of evidence.

Step 4: Identity and publishing

The passport is published under a canonical identifier based on the GS1 Digital Link standard, for example:

/01/08698765432104/21/SN-4471

Here 01 carries the product’s GTIN and 21 its serial number. The QR code is printed on the product or its packaging. The identifier never changes during the product’s life, while the content is versioned: when data is updated, the previous version is kept on record rather than overwritten.

Why server-side rendering matters

The passport page is generated on the server, so the full content is in the raw HTML. Customs and market surveillance automation can read it, archiving tools can capture it, and buyers’ screening systems can find the product. A passport drawn in the browser with JavaScript looks like an empty shell to all of them, which is not acceptable for a legal record that must last for years.

Step 5: Registry submission

ESPR, Regulation 2024/1781, provides for a central EU registry in which passport records are kept. Registration is built into the Provscope flow as its final step: each passport’s record is prepared for submission to the EU DPP registry once the registry is operational, so the passport is not just a page on a server but a document that can be registered in the system.

Who sees what?

Concern about trade secrets is the most legitimate objection in this field, and the answer is layered access. The same passport looks different depending on the role of the person accessing it:

• Public layer: open to everyone. Origin, material class, recycling and care information.
• Authorised layer (customs): embedded emissions detail, supply chain and verification record, after identity verification.
• Inspection layer (market surveillance): declarations of conformity, test reports and chain of responsibility, after identity verification.
• Closed layer: stays with the manufacturer.

Your recipe ratios, unit costs and supplier prices never leave the closed layer. They are kept in the system, but they are never disclosed.

What we need from you, what you get from us

Frequently asked questions

Get in touch to map the product tree of one of your product groups. Background: Digital Product Passport and CBAM.