Knowledge BaseImplementation

How to Manage Evidence for Digital Product Passports

Executive Summary

A Digital Product Passport publishes statements about a product. Some of those statements are descriptive and uncontroversial. Others are claims: recycled content, durability, substance content, repairability, origin, conformity. A claim is only as strong as whatever supports it, and the material that supports it is evidence.

How to Validate Digital Product Passport Data established how information is controlled on its way to publication, through the progression submitted, validated, accepted and publishable. That model deliberately separated four different questions: validation, verification, evidence and approval. This article takes the third of those and gives it a governed lifecycle of its own.

The central problem is that most organisations treat evidence as filing. A supplier sends a certificate, someone stores it, and the claim is considered handled. That approach fails in predictable ways. The certificate covers a different product variant. It expired eighteen months ago. It was issued to a facility rather than to the item being described. It has been superseded by a revised version nobody circulated. It was never associated with any specific claim, so nobody knows which passport statements depend on it. None of these failures are detectable by storage. They are detectable only by governance.

This article sets out The DPP Evidence Lifecycle, a vendor neutral model with nine stages, running from establishing whether evidence is required at all, through acquisition, collection, association, validation, verification or review, acceptance and controlled use, to monitoring, renewal and retirement. Alongside the lifecycle it defines a separate evidence state model, because where a piece of evidence is in a process is not the same thing as what status it currently holds.

Three principles run through everything that follows. First, evidence is not the same as the claim it supports, and its presence does not prove the claim. Second, evidence supporting a passport does not necessarily belong inside the passport, and the separation between the evidence environment and the publication surface is architectural rather than incidental. Third, not every passport data element requires documentary evidence at all, and confusing a legal evidence requirement with an internal enterprise control leads organisations to build expensive processes around information that never needed them, while under-controlling the claims that carry genuine regulatory exposure.

FrameworkTBF-034
The DPP Evidence Lifecycle

A nine stage governed evidence lifecycle covering evidence requirement, request and acquisition, collection, association, validation, verification or review, acceptance and control, controlled use and publication, and monitoring, renewal and retirement, supported by a separate evidence state model of received, associated, validated, verified, accepted and active with the alternative states rejected, expired, superseded and revoked, a claim to evidence relationship model, provenance, validity, versioning and supersession handling, access classification and a practical evidence register. It is built on the principle that evidence supports a claim rather than proving it, that evidence supporting a passport does not necessarily belong inside the passport, and that not every data element requires documentary evidence. It supplies the evidence dimension of the data validation control model TBF-033 at validation, verification, acceptance and publication, routes supplier evidence from the supplier readiness model TBF-032 into the same governed lifecycle rather than a separate architecture, is designed through stages two and three and operated through stages six to nine of the implementation roadmap TBF-031, and places evidence repositories inside the enterprise source and trust environment of the reference architecture TBF-030 while applying the governance, quality, stewardship and source of truth disciplines of TBF-023, TBF-025, TBF-026 and TBF-027.

Table of Contents

Definition

Definition
Digital Product Passport Evidence Management

The governed capability through which an organisation determines what evidence is required to support the information and claims carried by a Digital Product Passport, obtains that evidence from appropriate sources, associates it with the correct product scope and claim, validates and where required verifies it, accepts it under defined conditions, controls how and to whom it is exposed, and monitors it for expiry, supersession, revocation and change throughout the relevant product lifecycle.

Two boundaries in that definition do the heavy lifting. Evidence management is not document storage, because storage answers none of the questions above. And evidence management is not publication: deciding that evidence is sound is a separate decision from deciding that anyone outside the organisation should see it.

Why Evidence Management Matters

A passport makes claims durable, addressable and comparable. That is its value, and it is also its exposure. Before passports, a recycled content figure might appear in a technical file, a customer questionnaire and a marketing sheet, each with a different basis, and the inconsistency was rarely visible. Published, structured, machine readable claims remove that cover.

There are four practical reasons the evidence question cannot be deferred.

Claims attract scrutiny. Market surveillance authorities, customers, competitors and non-governmental organisations can all read published claims. Where a claim is challenged, the organisation is asked what supports it, and the answer needs to be retrievable at the level of the specific product or batch, not the general programme.

Evidence decays. Certificates expire, processes change, suppliers change, standards are revised and issuing bodies withdraw documents. A claim that was well supported at publication may be unsupported a year later without anything visible happening.

Scope errors are common and invisible. The most frequent evidence failure is not fabrication. It is a genuine document applied to the wrong product, variant, batch, facility, market or period. Storage will never surface this. Only explicit association will.

Evidence carries confidentiality risk in both directions. Under-exposing evidence can leave a required disclosure unmet. Over-exposing it can leak supplier terms, formulations, process detail or personal data. Both are governance failures, and both come from the same absence of an access classification.

Best Practice
Start from the claim, not the document

Evidence programmes that begin by collecting documents accumulate volume without assurance. Begin instead by listing the claims the passport will make, then ask, for each claim, whether evidence is required, on what authority, at what scope and for which audience. The document set falls out of that analysis. The reverse never works.

Data, Claims and Evidence

Precision here prevents most of the confusion that follows.

Data is information about the product: a value, a code, a date, a reference. A claim is an assertion the organisation makes using that information, whether descriptive or substantive. Evidence is information that supports, substantiates or demonstrates the basis for that claim, where evidence is required.

The recycled content example from How to Validate Digital Product Passport Data carries forward:

  • Claim: recycled content = 40%.
  • Evidence: the records, documentation, test information, certification or other supporting information that demonstrates the basis for that figure.

The presence of evidence does not prove the claim. Evidence itself may require validation, verification, scope assessment, validity assessment, provenance assessment and approval before it can be relied upon. An expired certificate is evidence. It is not support.

Tip

Four verbs, four decisions. Validation asks whether the information satisfies defined controls. Verification asks whether the claim is actually supported. Evidence is what verification examines. Approval is the organisation’s decision to stand behind the result. A programme should be able to say which of the four it has performed for any given claim.

What Counts as Evidence?

Evidence is far broader than uploaded documents. Treating it as a document management problem is the single most limiting assumption in this area, because it excludes the forms of evidence that are often the strongest.

Evidence may include:

  • certificates
  • declarations
  • test reports
  • laboratory results
  • technical documentation
  • supplier documentation
  • transaction records
  • production records
  • inspection records
  • audit records
  • measurements
  • lifecycle and event records
  • structured system records
  • digital credentials
  • other authoritative records

A structured record held in a system of record with controlled access, an audit trail and known ownership is frequently better evidence than a scanned certificate emailed by a supplier, because its provenance is intrinsic rather than asserted.

Common Mistake
Reducing evidence to PDFs

When evidence is defined as documents, organisations build document collection processes, measure document counts and store documents that nobody can associate with a claim. Meanwhile the production record, the test system result and the traceability event, which are structured, addressable, timestamped and attributable, are excluded from the evidence model entirely.

The DPP Evidence Lifecycle

The framework has nine stages. Stages 1 to 7 sit inside the governed evidence environment. Stage 8 is the controlled relationship with the passport. Stage 9 runs continuously around all of them.

The stages are ordered but not rigidly sequential. Evidence can loop back on discovery of a scope mismatch, and monitoring can return accepted evidence to reassessment at any point.

Stage 1: Evidence Requirement

Determine whether supporting evidence is required, and why.

Capture, for each claim or data element:

  • the claim or data element
  • the requirement source
  • the product scope
  • the jurisdiction
  • the evidence expectation
  • the responsible party
  • the access expectation
  • validity requirements where applicable

The requirement source must be recorded as one of distinct categories, and these should never be merged:

  • regulation: a legal obligation
  • delegated act: product specific requirements adopted under a framework regulation
  • conformity requirement: obligations arising from a conformity assessment route
  • standard: a technical standard, which may or may not be legally referenced
  • contractual requirement: an obligation to a customer, distributor or partner
  • organisational control: an internal decision about risk and assurance

The distinction matters operationally. An internal control can be adjusted by the organisation. A legal requirement cannot. When both are recorded as “required”, programmes lose the ability to prioritise under pressure, and the wrong things get relaxed.

Exit condition: the organisation understands what evidence is required, for what purpose, and on what authority.

Stage 2: Evidence Request and Acquisition

Determine where the evidence should originate, and who is responsible for obtaining it.

Possible origins include internal enterprise systems, suppliers, laboratories, certification and conformity processes, manufacturing systems, traceability systems, inspection processes and external authoritative sources.

Two failures are common at this stage. The first is assuming the supplier is the source when the authoritative record is actually internal. The second is leaving responsibility unassigned, so that the requirement exists in a specification but nobody is accountable for satisfying it.

Exit condition: a defined source and acquisition route exists for required evidence.

Stage 3: Evidence Collection

Receive or retrieve the evidence.

Collection is not synonymous with file upload. Evidence may be retrieved through an interface, referenced through an identifier, received as structured data, linked to an authoritative record, provided as a document, or generated through an enterprise process.

Whichever route applies, the collection event should record what was received, from whom, when, by what method and in what form. That record is the beginning of provenance.

Exit condition: the evidence has entered the governed evidence process and its source is known.

Stage 4: Evidence Association

Bind the evidence to the correct context. This is the stage most often skipped and most often responsible for failure.

Association may include product, product identifier, model, batch, lot, component, material, supplier, facility, claim, market, jurisdiction and lifecycle period.

Evidence may be entirely genuine and still inappropriate for a claim, because it applies to the wrong product, the wrong batch, the wrong facility, the wrong supplier or the wrong time period. A test report for a previous formulation is authentic and useless. Association is what converts a stored artefact into support for a specific statement.

Best Practice
Associate to the claim, not only to the product

Associating evidence to a product alone leaves the most important question unanswered: which statement does this support? A single product may carry a dozen claims with entirely different evidence requirements. Association at claim level is what makes it possible to answer “what supports this figure?” and, when evidence changes, “which published statements are affected?”

Exit condition: the evidence is unambiguously associated with the claim and scope it is intended to support.

Stage 5: Evidence Validation

Validate the evidence itself. This is validation applied to the evidence artefact, not to the underlying claim.

Potential controls include completeness, format, issuing and source information, product association, date, validity period, version, jurisdiction, scope, duplicate detection, required fields, and integrity where applicable.

These controls are drawn from the same discipline described in How to Validate Digital Product Passport Data, and the control classes defined there apply directly here. The model is not recreated: evidence is simply another category of governed information passing through defined controls, with its own severity handling and its own exception route.

Exit condition: the evidence satisfies the applicable structural and contextual controls.

Stage 6: Verification and Review

Determine whether the evidence actually supports the relevant claim, where verification or review is required.

Questions may include:

  • Does the evidence cover the correct product?
  • Does it support the stated claim, or something adjacent to it?
  • Is the evidence sufficiently current?
  • Is the source appropriate to the claim being made?
  • Does its scope match the intended use?
  • Are there conflicting records elsewhere in the organisation?
  • Is independent verification required?

Not every claim requires third party verification. Some claims require it because legislation, a delegated act or a conformity route says so. Others are appropriately handled by internal review proportional to risk. Treating every claim as requiring independent verification is as much a governance failure as treating none as requiring it, because it consumes assurance capacity on low risk statements and delays the ones that matter.

Exit condition: the evidence has an appropriate verification or review status for the intended use.

Stage 7: Acceptance and Control

Determine whether the evidence is accepted for use, and under what conditions.

Capture acceptance status, owner, approval where required, restrictions, effective date, expiry date, version, supersession relationship and access classification.

Possible states might include pending, accepted, rejected, expired, superseded and revoked. These are educational examples of governed status values, not regulatory classifications, and organisations should define the set their processes actually need.

Acceptance is conditional by nature. Evidence accepted for a specific market, a specific batch range and a specific period is not accepted generally, and the conditions should be recorded alongside the decision rather than remembered by the person who made it.

Exit condition: the organisation knows whether the evidence can support the relevant information and under what conditions.

Stage 8: Controlled Use and Publication

Determine how the accepted evidence relates to the passport. Five outcomes are worth distinguishing:

  • Claim only. The passport exposes the accepted claim, with the supporting evidence held entirely within the enterprise environment.
  • Claim and status. The passport exposes the claim together with an evidence or verification status, such as an indication that the claim has been independently verified.
  • Claim and reference. The passport provides a controlled reference to supporting evidence, without exposing the evidence content itself.
  • Selected evidence. Specific evidence is accessible to an authorised audience, such as an authority, a downstream economic operator or a recycler.
  • Restricted evidence. Evidence remains within controlled enterprise or regulatory processes and is not exposed through the passport at all.

Different audiences may receive different outcomes for the same claim. A general consumer, a downstream economic operator, a repairer, a recycler and a market surveillance authority are not the same audience and do not necessarily have the same entitlements.

Exit condition: evidence is used or referenced according to the applicable publication and access rules.

Stage 9: Monitoring, Renewal and Retirement

Evidence has a lifecycle, and the passport is a persistent publication. The two facts together make monitoring unavoidable.

Monitor for expiry, supersession, revocation, product change, supplier change, regulatory change, claim change, new evidence, validity periods and changed scope.

Possible outcomes are renew, replace, reverify, supersede, revoke and retire.

When evidence status changes, the passport may need updating. That link is the operational point of the entire lifecycle: an evidence expiry that does not reach the claims that depend on it is an expiry nobody has actually managed.

Exit condition: evidence remains current, traceable and appropriately linked throughout the relevant product lifecycle.

Evidence States

Lifecycle stage and evidence status are different concepts and should be modelled separately. Stage describes where evidence is in a process. Status describes what the organisation currently holds.

A concise state model might run:

RECEIVED
   ↓
ASSOCIATED
   ↓
VALIDATED
   ↓
VERIFIED / REVIEWED (where required)
   ↓
ACCEPTED
   ↓
ACTIVE

with alternative states rejected, expired, superseded and revoked.

The distinction has a practical consequence. A piece of evidence may have completed stage 7 and hold status “accepted”, then move to status “expired” without moving backwards through any stage. Systems that model only stages cannot represent that, and typically resort to deleting or overwriting the record, which destroys the history the organisation will need if the claim is ever questioned.

Common Mistake
Modelling status as a stage counter

Where “current stage” is the only field, expiry, revocation and supersession have nowhere to live. Teams then either reset the evidence to an earlier stage, losing the fact that it was once accepted, or leave it marked as complete while it is no longer valid. Keep stage and status as separate governed attributes.

Claim to Evidence Relationships

Relationships between claims and evidence are frequently not one to one, and a model that assumes they are will misrepresent reality within weeks.

  • One claim, one evidence item. A single test report supports a single stated value. This is the simplest case and the least common for substantive claims.
  • One claim, multiple evidence items. A recycled content figure may rest on a supplier declaration, a material composition record and a test result, none of which is sufficient alone.
  • Multiple claims, one evidence item. A single management system certificate or test report may be referenced by several claims across several products.
  • Evidence chain. Several pieces of evidence collectively support a claim, each supporting a different link: input material origin, processing, blending ratio, output composition.

Scope differences matter as much as cardinality. Evidence issued at one level does not automatically substantiate claims at another. A certificate applying to a manufacturing facility does not automatically substantiate every product level claim associated with that facility. A material level declaration does not automatically substantiate a finished product claim after processing, blending or assembly has changed the composition.

Example
Where the chain breaks

A finished product claims 40% recycled content. The supplier holds a certificate confirming that its recycling facility is certified. That certificate substantiates something real: the facility operates a certified process. It does not substantiate that this specific batch of material, delivered on this date, into this production run, contained 40% recycled content. The gap between facility level and batch level is precisely where evidence chains are needed, and precisely where they are most often assumed rather than constructed.

Evidence Provenance

Provenance is the record of where evidence came from and what has happened to it since. It is not the same as file metadata: a creation timestamp and an author field describe a file, not the authority of the information inside it.

Useful provenance information may include origin, issuer or source, supplier, creation date, collection method, product association, transformations, validation history, verification history, approval history, version and supersession relationships.

Provenance is what allows an organisation to answer a challenge without reconstruction. Without it, the answer to “where did this come from?” is an archaeology exercise across mailboxes and shared drives, performed under time pressure, usually by someone who was not involved at the time.

Chain of Custody and History

For some evidence, knowing the origin is not enough: what happened to it after creation matters too.

This should be stated carefully. Formal legal chain of custody, in the evidentiary sense, is not a general requirement for passport evidence, and implying otherwise misleads. What is true is that higher value or higher risk evidence may justify stronger controls around origin, integrity, transfer, modification, access and approval. A laboratory result underpinning a regulated substance claim warrants tighter handling than an internal photograph of a label.

The proportionality principle applies: controls should reflect the consequence of the evidence being wrong, not the convenience of applying the same process everywhere.

Evidence Validity and Expiry

Evidence may cease to support a claim because:

  • it expires
  • the product changes
  • the supplier changes
  • the manufacturing process changes
  • the scope changes
  • the issuing body withdraws it
  • new evidence supersedes it
  • regulatory requirements change

The important governance question is what an organisation does when validity lapses. The possible responses include revalidation, re-verification, claim withdrawal, passport update and escalation. The correct response depends on the claim, the requirement source, the jurisdiction and the risk, and there is no universal answer. What is not acceptable is having no defined response at all, because the default in that case is that the published claim continues unchanged while its support has quietly disappeared.

Tip

Distinguish between the expiry of the evidence and the expiry of the claim’s support. A certificate that expires may be replaced by an equivalent one within the same validity chain, leaving the claim continuously supported. Alternatively, expiry may leave a genuine gap in support for a defined period. These are materially different situations and should be recorded differently.

Evidence Versioning and Supersession

Four related but distinct concepts should not be collapsed:

  • New version. The same evidence, reissued or amended, typically retaining continuity of scope and issuer.
  • Superseded evidence. Evidence replaced by a later item that now carries the support. The earlier item remains part of the record of what was relied upon at the time.
  • Revoked evidence. Evidence withdrawn by the issuing body or source, which may invalidate reliance retrospectively rather than only prospectively.
  • Expired evidence. Evidence that has passed the end of its validity period without being withdrawn.

Do not simply overwrite evidence history. If a passport published a claim in March on the basis of one document, and that document was replaced in September, the organisation should still be able to show what supported the March publication. Overwriting removes the ability to answer questions about past states, which is exactly when questions tend to arise.

The depth of history maintained should be proportionate to the requirement and the risk. Full version history for every internal record is rarely necessary; it is close to essential for evidence supporting regulated claims.

Evidence Access and Confidentiality

Evidence frequently contains commercially sensitive information, supplier confidential information, technical detail, personal data or restricted compliance information.

The governing principle is short: “evidence exists” does not mean “evidence should be public.”

Supplier declarations may contain pricing, volumes or sourcing relationships. Test reports may contain formulations. Audit records may contain named individuals. Publishing evidence wholesale to satisfy a perceived transparency expectation can breach confidentiality obligations, damage supplier relationships and expose personal data.

Every evidence item should therefore carry an access classification, set at acceptance and re-evaluated when the item is referenced from a new context. This connects directly to the access and discovery capabilities described in Building an Enterprise Digital Product Passport Architecture and to the publication controls in How to Validate Digital Product Passport Data.

Best Practice
Classify at acceptance, enforce at publication

Access classification is cheap to set at the moment of acceptance, when the source, contents and sensitivity are all in front of the person deciding. It is expensive and error prone to determine later, at publication time, by someone reading a document out of context under a deadline.

Evidence Repositories

An evidence repository is a logical architectural capability, not a prescribed product or a single database.

The capability may be delivered by a document management capability, a compliance system, a product lifecycle management environment, a quality management system, a supplier system, a data platform, an external trusted source, or several federated systems operating together.

Organisations do not need one central evidence database. What they need is controlled evidence management: known location, known owner, known access rules, known status and a reliable way to reach the evidence from the claim it supports. A federated arrangement, where laboratory results remain in the laboratory system and conformity documentation remains in the compliance system, satisfies that requirement provided the association and status information is governed.

Common Mistake
Mandating one central repository

Consolidation projects that attempt to move all evidence into a single store typically stall, because the authoritative systems have legitimate reasons to hold their own records and their owners have no incentive to surrender them. The architectural requirement is controlled evidence management, not physical centralisation. Federate the storage; govern the register.

Building an Evidence Register

An evidence register is a practical implementation concept, not a prescribed regulatory artefact. It is the governed index that makes federated evidence usable: it records what evidence exists, what it supports, what state it is in and where to find it, without requiring the evidence itself to be moved.

Useful fields include:

FieldPurpose
Evidence IDStable internal identifier for reference and traceability
Evidence typeCertificate, test report, declaration, structured record, and so on
Claim / data elementWhat the evidence supports
Product / product scopeProduct, model, batch, lot, component, material, facility
Source / issuerWho produced or issued it
OwnerAccountable internal role
Requirement sourceRegulation, delegated act, conformity, standard, contract, internal
Effective dateWhen support begins
Expiry dateWhen validity ends, where applicable
Validation statusResult of stage 5 controls
Verification statusResult of stage 6, including “not required”
Acceptance statusGoverned status from the state model
Access classificationWho may see it, and in what context
VersionVersion of the evidence item
Superseded byLink to the replacing item, where applicable
Evidence location /referenceWhere the evidence actually resides

The register is what makes the difficult questions answerable in minutes rather than weeks: which claims are supported by evidence expiring in the next ninety days, which evidence has no owner, which accepted evidence has never been associated with a product, and which published passport statements depend on an item that has just been revoked.

Tip

A register with fifteen well maintained fields across the claims that actually require evidence is worth far more than an exhaustive register covering everything the organisation has ever filed. Scope the register to claims with evidence requirements, then extend it if the case is made.

Supplier Evidence

How to Prepare Suppliers for Digital Product Passports establishes how suppliers are segmented and brought to readiness. Suppliers may provide data, evidence, or both, and the two are frequently confused in supplier communications: a request for a recycled content percentage and a request for what supports it are different asks with different formats and different owners.

The governing rule is that supplier evidence enters the same governed evidence lifecycle as internally generated evidence. There is no separate supplier evidence architecture. The same nine stages apply, the same state model applies, and the same register holds it.

What differs is the level of control, which should be proportionate to supplier segment. Higher risk segments, or segments supplying materials underpinning regulated claims, may justify stronger evidence controls: independent verification, tighter validity windows, mandatory structured formats, or scheduled re-collection. Lower risk segments may be handled through declaration and periodic review. This is the same proportionality principle that drives supplier segmentation, applied to evidence rather than to onboarding.

Supplier evidence should always carry source, scope, product association, validity, owner, status and a defined remediation path. The remediation path matters most: when supplier evidence fails validation or verification, someone must be accountable for going back to the supplier, and the claim must not proceed on the assumption that the gap will close.

Internal Enterprise Evidence

Internally generated evidence is not automatically trustworthy, and the assumption that it is produces a governance blind spot that is often larger than the supplier one.

Internal evidence may be produced by manufacturing systems, quality processes, laboratories, inspection routines or engineering teams. It still requires ownership, association, validation, version control, approval where relevant, and lifecycle monitoring. An internal test result with no recorded owner, no product association and no version is no more usable in a challenge than an unattributed supplier document.

Internal evidence carries two specific risks. The first is informality: because the producer is internal, evidence is often communicated rather than recorded, and the record is a message rather than a governed artefact. The second is silent change: an internal process is modified, the evidence it produced remains on file, and nobody links the process change to the claims that relied on the earlier output.

Evidence and DPP Publication

The architectural position is straightforward and worth stating plainly: the passport is a publication surface, not the authoritative evidence repository.

Within the reference architecture described in Building an Enterprise Digital Product Passport Architecture, evidence sources and repositories sit inside the enterprise source and trust environment. The logical passport service consumes what the publication model requires: the claim, an evidence or verification status, a controlled reference, or selected evidence. It does not become the system in which evidence is authored, owned or governed.

This separation is what makes the access model workable. Because evidence remains under enterprise control, the passport can expose different views to different audiences without duplicating or relocating anything. It is also what keeps the passport maintainable: a passport that has absorbed the evidence estate has inherited the evidence estate’s expiry, versioning and confidentiality problems as well.

The relationship to the validation model is equally specific. Evidence influences four points in the control progression established by TBF-033: it is examined during validation where evidence rules apply, it is the subject of verification, it informs the acceptance decision, and its access classification constrains publication. Evidence does not create a parallel control path; it feeds the existing one.

Evidence Across the DPP Implementation Roadmap

Evidence management is not a late stage activity, although it is frequently treated as one.

Within How to Build a Digital Product Passport Implementation Roadmap, evidence work begins during Stage 2, Information Requirements, where the evidence expectation attached to each claim is identified alongside the claim itself, and continues into Stage 3, Data and Source Assessment, where the organisation discovers whether the evidence exists, who holds it and in what condition.

It becomes operational through Stage 6, Build and Integrate, where evidence association, register and access mechanisms are implemented; Stage 7, Validate and Assure, where evidence controls are proven; Stage 8, Pilot and Deploy, where the process is exercised on real products and the first expiries and mismatches surface; and Stage 9, Operate, Scale and Improve, where monitoring, renewal and retirement become routine operations rather than incidents.

Programmes that defer evidence to stage 8 discover their evidence gaps at the point where the schedule has no remaining flexibility. The gaps are almost always upstream, in supplier relationships and internal record keeping, and they take months rather than weeks to close.

Practical Example

Continuing the recycled content example, at a claimed 40%.

Requirement. The claim falls within scope of an applicable product requirement. Stage 1 records the claim, the requirement source, the product scope (a specific model, across defined batches), the jurisdiction, the evidence expectation, the responsible party and the access expectation: confidential, not for general publication.

Evidence received. The supplier provides a declaration of recycled content together with a material composition record. Stage 3 records the source, method and date of receipt.

Association. Stage 4 binds the evidence to the product, the material, the supplier and the batch range the claim covers.

Validation. Stage 5 applies structural and contextual controls. The declaration is complete, correctly formatted, signed, in date and attributed to the correct supplier entity. This is validation.

Scope mismatch discovered. Association reveals that the composition record covers a material grade supplied before a formulation change, and does not cover the batch range in the claim. The evidence is authentic and out of scope.

Exception and remediation. An exception is raised, an owner is assigned and the supplier is asked for a record covering the correct batch range. The claim does not proceed in the interim.

Replacement evidence received. A composition record covering the correct grade and batch range is provided, associated and validated.

Review and verification. Because the claim carries regulatory significance, a review confirms that the composition record and declaration together support 40% for these batches, and that no conflicting internal record exists. Where the applicable requirement calls for independent verification, that verification is obtained. This is verification.

Accepted. Stage 7 records acceptance, the owner, the effective date, the expiry date derived from the supplier declaration’s validity period, the version, and the access classification. This is acceptance.

Published. The passport exposes the claim and a verification status. The supporting evidence is not exposed to general users; a controlled reference is available to authorised parties. This is publication.

Later event. Eleven months on, the supplier declaration reaches its expiry date and, separately, is superseded by a revised declaration reflecting a new input mix.

Monitoring trigger. Stage 9 raises both events against the register. This is monitoring.

Status change. The original declaration moves to status “expired” and is marked as superseded by the revised item. The affected claims are identified through the register’s claim associations.

Reassessment. The revised declaration is collected, associated, validated and reviewed. The revised input mix supports 38%, not 40%.

New evidence and passport update. The claim value is corrected through the governed data progression, and the passport is updated. The earlier evidence and its acceptance record are retained, so the organisation can still demonstrate what supported the original published figure at the time it was published.

Example
What the example demonstrates

Every failure in this sequence was procedural, not fraudulent. Authentic evidence with the wrong scope, a valid declaration that expired, and a supported claim that became unsupported through a supplier process change. None of these are detectable by storing documents. All of them are detectable by association, status and monitoring.

Evidence Metrics

Useful measures include:

  • evidence completeness against claims that require evidence
  • number of claims requiring evidence, by requirement source
  • evidence coverage across products in scope
  • validation pass rate for evidence items
  • verification backlog
  • expired evidence still referenced by active claims
  • evidence expiring within defined periods, such as thirty, sixty and ninety days
  • rejected evidence, by reason
  • remediation time from exception to resolution
  • evidence without product association
  • evidence without an owner
  • superseded evidence still referenced
  • supplier evidence failure rate, by segment
  • passport claims affected by evidence status changes

The measure most often reported is the least informative. The number of documents collected is not an evidence quality metric. It rises when suppliers send more material, regardless of whether that material is in scope, current, associated or relevant. An organisation can double its document count and reduce its assurance at the same time. The metrics that matter describe relationships and states: what is associated, what is current, what is owned, and what is affected when something changes.

Tip

If only three measures can be maintained, choose evidence expiring within ninety days, evidence without product association, and claims requiring evidence that currently have none. Between them they surface the failures that cause published claims to become unsupported.

Common Mistakes

Common Mistake
Every DPP field needs a PDF

Evidence requirements depend on legislation, delegated acts, product specific requirements, conformity requirements, the type of claim, contractual requirements, organisational controls, risk and intended use. Many descriptive data elements require no documentary evidence at all. Applying a blanket requirement consumes effort that should be directed at the claims carrying genuine exposure.

Common Mistake
If evidence exists, the claim is proven

Evidence may be out of scope, expired, superseded, revoked, issued for a different product, or simply not addressed to the claim being made. Existence is the start of assessment, not its conclusion.

Common Mistake
Supplier evidence is automatically trusted

Supplier evidence enters the same lifecycle as internal evidence: association, validation, verification where required, acceptance and monitoring. Trust in a supplier relationship is not a substitute for control over a specific artefact supporting a specific claim.

Common Mistake
Evidence belongs inside the passport

The passport is a publication surface. Evidence lives in the enterprise source and trust environment, and the passport exposes the claim, a status, a reference or selected evidence according to the applicable rules. Embedding the evidence estate in the passport imports its confidentiality and lifecycle problems into a public surface.

Common Mistake
One evidence item supports every related claim

Scope differs by level. A facility certificate does not substantiate every product level claim associated with that facility, and a material declaration does not automatically substantiate a finished product claim after processing or blending.

Common Mistake
Evidence never changes

Evidence expires, is revised, is superseded and is occasionally withdrawn by the issuer. A model without versioning and supersession cannot represent what actually happens, and defaults to overwriting history.

Common Mistake
Expired evidence can remain because the claim is already published

Publication is not a permanent grant. A published claim whose supporting evidence has expired or been revoked is a live exposure, and the organisation should have a defined response: revalidation, re-verification, claim withdrawal, passport update or escalation.

Common Mistake
Uploading a document is evidence management

Upload is stage 3 of nine. Without requirement definition, association, validation, verification where required, acceptance conditions, access classification and monitoring, an upload is storage with no assurance value.

Common Mistake
Internal evidence does not require governance

Internally produced evidence needs ownership, association, validation, version control, approval where relevant and lifecycle monitoring. Informality and silent process change make internal evidence a common blind spot precisely because it feels trustworthy.

Common Mistake
Evidence and verification are the same thing

Evidence is the supporting information. Verification is the assessment of whether that information supports the claim. Holding evidence is not the same as having verified anything, and stating a verification status the organisation has not actually reached is a serious misrepresentation.

Common Mistake
More evidence always means stronger assurance

Volume without association, currency and scope alignment adds review burden rather than assurance, and increases the likelihood of internal contradiction. Three well scoped, current, associated items are stronger than thirty unclassified files.

Common Mistake
One central repository is mandatory

The architectural requirement is controlled evidence management, not physical centralisation. Federated repositories with a governed register satisfy it, and usually survive contact with the organisation better than a consolidation programme.

Frequently Asked Questions

Does every Digital Product Passport data element require evidence?
No. Evidence requirements depend on applicable legislation, delegated acts, product specific requirements, conformity requirements, the type of claim, contractual requirements, organisational controls, risk and intended use. Many elements are descriptive and carry no documentary evidence requirement. The organisation should be able to say, for each element, whether a requirement exists and from which category of source.

Must supporting evidence be published in the passport?
No. Whether evidence is exposed, and to whom, depends on the applicable requirements and access rules. The passport may expose the claim alone, the claim with a status, a controlled reference, selected evidence for an authorised audience, or no underlying evidence at all to general users.

Does every claim require independent third party verification?
No. Some claims require it because legislation, a delegated act or a conformity route requires it. Others are appropriately handled through internal review proportional to risk. The requirement should be determined per claim from its requirement source, not applied uniformly.

Is there a mandated evidence format?
No single format is mandated across product categories. Evidence may be structured data, a credential, a record in an authoritative system or a document. Specific requirements may apply within particular regulatory or conformity contexts.

Do we need a blockchain or a distributed ledger for evidence integrity?
No. Integrity controls may be appropriate for high risk evidence, and there are several ways to achieve them. No specific technology is required by the framework, and none should be selected before the evidence requirements are understood.

Where should the evidence register live?
Wherever the organisation can govern it. It may sit within a compliance system, a product lifecycle environment, a data platform or a governed dataset. What matters is that it is maintained, owned and reachable from the claims it describes.

What is the difference between an evidence repository and the evidence register?
The repository holds the evidence. The register records what evidence exists, what it supports, what state it is in and where it resides. An organisation may have many repositories and one governed register.

How does this relate to the validation model in KB-0033?
That model governs the progression of information towards publication. This framework governs the supporting evidence that feeds it. Evidence is examined during validation where evidence rules apply, is the subject of verification, informs acceptance, and constrains publication through its access classification.

Key Takeaways

Key Takeaways

References

About This Article

About This Article
Last Reviewed
2026-08-09
Next Scheduled Review
2027-08-09
Article Version
1.0

tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve.