A Digital Product Passport can tell you that a product contains 40% recycled material.
But can it tell you why?
That distinction is becoming increasingly important for manufacturers.
A Digital Product Passport can tell you that a product contains 40% recycled material.
But can it tell you why?
That distinction is becoming increasingly important for manufacturers.
Publishing a sustainability claim is a data-output problem. Defending it is a data-lineage problem. That is where DPP implementation becomes more than creating a digital record for a product. It becomes a question of how the product data and evidence behind that record are structured, connected and governed.
The “40%” Is Not a Data Field
One of the easiest mistakes in a DPP project is to treat a sustainability claim as another product attribute. For manufacturers, already working on DPP implementation, This raise a more practical question: What happens when a sustainability claim needs to be proven and not simply published?
One of the easiest mistakes in a DPP project is to treat a sustainability claim as another product attribute.
That 40% may have been calculated from several components. Those components may come from different suppliers. Supplier declarations may be supported by certificates. The certificates may have expiry dates. The calculation may depend on material composition data held in another system.
So instead of treating the claim as an isolated value, the DPP needs to understand the relationships behind it.
Standard Product Record
The Limitation: Flat data presents values as isolated facts without backing evidence.
Connected Data Graph
Recycled Content (40%) = [Supplier Batch #B820] + [Tier-2 Processing Claim] + [ISCC+ Certification #9823]
Data lineage tracks every upstream transformation, connecting raw material inputs to the final product record.
Cryptographic / System Verification
| Product | Product/SKU and applicable configuration | Product A, SKU 10482 |
| Component | Parts contributing to the product | Housing, casing, packaging |
| Material | Material composition and attributes | Recycled polymer |
| Source Data | Original operational or supplier data | Supplier declares 80% recycled content |
| Evidence | Supporting documentation or verification | Supplier certificate |
| Calculation | Method used to derive the claim | Product-level recycled-content calculation |
| Claim | Final value exposed through the DPP | 40% recycled material |
| Status | Validity and review state | Verified / review required |
The implementation needs clear rules for:
→ required supplier data
→ acceptable evidence types
→ submission formats
→ validation
→ ownership
→ update frequency
→ exception handling
For example, a manufacturer could require a supplier to provide recycled-content information together with supporting evidence and an effective date.
The DPP system can then validate the submission against defined rules before the information becomes eligible for downstream product claims.
The DPP does not eliminate supplier-data problems.
It gives manufacturers a framework in which those problems can be identified, controlled and connected to the products they affect.
Build the data, integrations, validation workflows, and evidence model needed to support sustainability claims.
AI can help process evidence, but it should not automatically become the authority for the claim. For example, AI can extract information from supplier certificates, identify missing fields, compare documents, or flag inconsistencies. The underlying source remains the evidence, while validation and human approval should determine whether the extracted information can support a published claim.
Yes. In many cases, a claim depends on several evidence sources rather than a single certificate or report. A DPP evidence model should allow multiple records to be linked to the same claim, while preserving the relationship between each source, the calculation performed, and the final product-level value.
At minimum, the evidence should capture its source, issuer, applicable product or material, scope, creation date, validity period, version, and relationship to the relevant claim. Depending on the use case, methodology, verification status, and approval history may also be required. The objective is to make the evidence identifiable and usable in context, rather than storing it as an isolated file.
The existence of two valid documents does not automatically determine which value should be published. The organization needs defined rules for assessing scope, methodology, measurement date, applicability, and authority. Where the difference cannot be resolved automatically, the conflicting evidence should be routed for review with both sources retained in the audit trail.
The integration layer should capture the calculation’s relevant metadata alongside its result rather than importing only the final number. This can include the source datasets, calculation method, version, timestamp, and resulting metric. That allows the DPP to reference the calculation as part of the evidence chain without turning the DPP into the organization’s entire calculation engine.