From Data to Data Carrier: Why Label Print Verification Is the Last Mile of DPP Compliance

Most Digital Product Passport projects start with the data. Where does material composition data come from? Who owns carbon footprint calculations? Which registry will host the record? Questions which tend to absorb most of the budget and attention in early DPP planning. 

But a passport isn't complete when the data is correct. There’s still the last mile to go…

Data is complete when a physical product, sitting on a shelf or arriving at a recycling facility years later, can be scanned and resolved back to that data reliably.

The last mile is everything between "the data is correct" and "the product reliably resolves to it" — and it's the part of DPP compliance that gets the least attention relative to how easily it can fail. 

The chain a passport depends on 

Strip away the sustainability framing and a Digital Product Passport is a chain of dependencies: 

1. Product master data is correct and complete 

2. A unique identifier is generated and correctly associated with that data 

3. The identifier is encoded into a data carrier — a QR code, DataMatrix, or RFID tag 

4. The data carrier label is printed or written onto the physical product or its packaging 

5. The printed label remains scannable through handling, storage, transit and years of use 

6. A scan resolves correctly back to the right record, every time, for anyone who needs it 

Why the last mile is where things usually go wrong 

Data governance failures tend to be systemic and visible — a missing field, an unpopulated record, a broken integration. They get caught in testing because they fail consistently and obviously. 

Last mile failures are different. They're often intermittent, condition-dependent and invisible at the point of label production, i.e. whilst it looks good, it might not be right: 

• A code that encodes the right identifier but prints below a usable contrast grade 

  • it scans fine on a handheld scanner in good light during a production-line test then fails on a fixed-mount scanner in a dim warehouse two years later. 

• A code and its human-readable text that briefly disagree 

  • because of a print buffer issue or a last-second data correction that didn't propagate to both - invisible unless someone is checking the two against each other. 

• The same identifier appearing on two different units 

  • produced at different times or different sites – slipped through as there was no process for checking for duplicates beyond the current print batch. 

None of these show up in a review of your product data. But all of them break the passport for whoever tries to use it. 

Verification is what turns "printed" into "compliant"

The practical implication is that DPP compliance can't be fully assessed by auditing your data systems. It requires verifying what actually leaves the printer, on an ongoing basis and not just at initial set up.  

What does good verification look like? 

• Grading every code against a recognised barcode/2D symbol standard - marginal print quality is caught before it becomes a field failure, not just confirmed to scan in good conditions. 

• Matching encoded data against source records and human-readable text at the point of print - catching the gap between "the data was correct" and "the label is correct" before the product leaves the line. 

• Checking for duplicate identifiers in real time, across all manufacturing sites - not just within a single print run at one site; a passport that re-uses another product's identity is arguably a worse failure than one that doesn't scan at all. 

• Logging the verification itself - if a passport is later queried and found faulty, there's a record of what was checked and when, rather than an assumption that it must have been fine. 

The Last Mile is where the liability sits

This matters more than it might first appear because DPP liability for accuracy rests with the business placing the product on the EU market — not with whoever supplied the printer, the labelling software or the master data system. 

If a passport fails at the point someone needs it, "our data was correct" won't be a complete answer if the printed label wasn't verified to reliably reflect that data. 

Getting the data layer right is necessary - and it's where most current DPP planning is rightly focused - but it isn't sufficient on its own. The last mile — verifying what's actually printed, not just what was intended — is what turns a correct database record into a passport that holds up under real-world use. 

Perceptor IoT verifies every code at the point of print — grading, content matching and global duplicate checking — so the printed label content that your Digital Product Passport depends on is confirmed as correct, not just assumed to be.

Get in touchT

he Perceptor team can talk through how you can achieve this across all your production lines and manufacturing sites.