Digital Product Passport Example: Evidence Walkthrough

A worked Digital Product Passport example

A useful Digital Product Passport example begins with requirements and evidence, not a QR-code mockup. This walkthrough uses a completely synthetic product to show how product data, supplier documents, provenance, review status, access rules, and publication readiness can fit together.

It is not a statutory template. Actual DPP data, carrier, granularity, access, and timing depend on the legislation and delegated act applying to the product group. Regulation (EU) 2024/1781 says product-group measures can specify the data, carrier, presentation, access before sale, and whether a passport exists at model, batch, or item level. The official text is available in the Ecodesign for Sustainable Products Regulation.

Synthetic product and scope

The invented product is:

• product family: Field Jacket;
• model: FJ-100;
• color: navy;
• batch: B-2026-07;
• brand: Example Works;
• supplier group: fabric, zipper, thread, assembly;
• intended market: defined by the project's qualified scope review.

The project has not yet decided whether the final passport will be model-, batch-, or item-level. It records that decision as pending rather than defaulting to item-level because a software demo happens to support serial numbers.

The example uses three configured evidence requirements:

1. material origin;
2. recycled-content claim support;
3. carbon declaration.

These are illustrative readiness fields. They are not presented as the complete legal requirements for jackets.

Step 1: Create the requirement register

Each requirement gets a controlled record:

The record also needs a source, rule version, product scope, review status, and effective date. In a real implementation, those fields come from qualified analysis of current product-group requirements.

Step 2: Receive supplier evidence

Supplier SUP-14 provides:

• material-origin-v2.pdf;
• recycled-content-v1.pdf;
• no carbon declaration.

The intake workflow records:

• supplier identity;
• upload time;
• product and component association;
• document version;
• file type and size;
• cryptographic content hash;
• submitter;
• current review state.

A content hash helps show whether the reviewed file later changed. It does not validate the truth of the document or the supplier claim.

The carbon requirement remains missing. The system should not create an empty file, reuse evidence from another product, or mark the field not applicable without an authorized decision.

Step 3: Review evidence

The reviewer evaluates the material-origin document and accepts it for this configured readiness review. The decision stores:

• reviewer;
• decision time;
• evidence version and hash;
• requirement code;
• reason or checklist result;
• expiry or next-review date if applicable.

The recycled-content document remains pending because the declared percentage does not yet map clearly to the product's bill of materials. The reviewer asks the supplier for clarification.

The state is now:

This table is more useful than “67% complete.” Pending and missing require different actions, and one accepted field does not carry the same importance as another in every rule set.

Step 4: Connect source data

The passport workflow should not become an accidental product master. For each candidate field, record its authoritative source:

• model and variant: PIM;
• component relationship: PLM or bill-of-materials source;
• supplier identity: procurement system;
• accepted evidence: controlled evidence store;
• public product page: publication service;
• identifier: approved identity service.

If two systems disagree, route an exception. Do not silently choose the most recent timestamp.

Step 5: Define access

Not every datum or document should be public. The synthetic design separates:

• public product facts: fields approved for consumer access;
• economic-operator evidence: fields available to an authorized supply-chain actor;
• authority access: data made available under the applicable rule and role;
• internal review evidence: drafts, comments, personal data, and confidential supplier documents.

The access design must follow the actual legal and commercial requirements. “Stored in the passport” should not mean “visible to anyone who scans a code.”

The ESPR text includes conditions around access and personal data. Avoid placing customer personal data in a passport merely because the system can.

Step 6: Choose identity and carrier only after scope

The implementation team now evaluates:

• required identifier scheme;
• model, batch, or item granularity;
• data carrier type;
• carrier placement;
• resolver or lookup behavior;
• durability through the expected lifecycle;
• what happens when packaging or the record changes.

The team tests with a non-production identifier. A rendered QR code is a transport entry point. It is not evidence that the record satisfies the product rule.

Step 7: Test registry interaction

On 20 July 2026, the European Commission announced that the Digital Product Passport Registry and testing environment were live. A project can use current official documentation to validate the applicable registration workflow.

A robust connector should retain:

• request version and non-secret correlation ID;
• record or identifier submitted;
• response status;
• validation errors;
• retry decision;
• final acknowledgement;
• evidence of which software and rule version produced the payload.

Testing the environment does not prove production acceptance or legal readiness.

Step 8: Run the publication gate

The synthetic product cannot yet pass a full gate because recycled content is pending and carbon evidence is missing under its configured map.

The gate asks:

• Are all mandatory configured requirements resolved?
• Are candidate public values linked to accepted evidence?
• Are source versions current?
• Is identity granularity approved?
• Is the carrier tested?
• Are access classes implemented?
• Has registry behavior been validated?
• Are corrections and withdrawal supported?
• Has an authorized person approved publication?

The product can remain in readiness review without publishing unsupported claims.

What the public view might show

After applicable requirements are resolved and publication is approved, a public view might include:

• product identity;
• manufacturer or economic-operator information required for the product;
• material or sustainability facts approved for public display;
• repair, durability, or end-of-life information where applicable;
• record version and last update;
• accessible explanation of fields;
• a route for corrections or support.

The exact fields must come from the applicable product measure, not this example.

Evidence dossier behind the view

For each displayed value, the internal dossier should answer:

• Which requirement does it address?
• What source supplied it?
• Which document or structured record supports it?
• Who reviewed it?
• Which version and hash were reviewed?
• When does it expire or need reassessment?
• Who is allowed to see the evidence?
• What happens if the value changes?

This makes the passport explainable without exposing confidential documents publicly.

Failure examples worth testing

Supplier replaces a file

The hash changes. The accepted decision remains tied to the old version, and the new file returns to review.

Product mapping changes

A different fabric supplier is assigned to the batch. Evidence linked to the former supplier cannot automatically support the new batch.

Registry request times out

The connector checks the resulting state before retrying so it does not create a duplicate registration.

Public value is corrected

The new version is published while the prior value and decision remain auditable under the retention policy.

Requirement source changes

The workflow identifies affected products and opens reassessment rather than rewriting historical evidence.

What this example does not prove

It does not define the complete requirements for textiles or any other product group. It does not certify the jacket, verify the supplier's claims, select a lawful identifier, guarantee registry acceptance, or establish compliance.

The European Commission's DPP framework and standards page should be read with the applicable regulation and product-specific measures.

To work through the same accepted, pending, and missing evidence states, run the EvidencePass sample and use the same page to request a paid DPP evidence-readiness review. The sample does not publish or register a passport.