How Should Product Evidence Travel Downstream?
What should travel with a product fact so a downstream business can reuse, verify or challenge it? A practical evidence-envelope model for cross-company product data.
Direct answer
Do not hand off only the value. Preserve enough context to know what the value describes, how it was established, which product, model, batch or item it belongs to, who issued or holds the evidence and whether it is still current.
A product fact becomes genuinely reusable when the next business receives more than the value. This page sets out a practical evidence envelope for carrying the fact, its scope and its supporting context across company boundaries without pretending one format or technology makes the claim true.
As at 10 September 2026, there is no single cross-sector evidence envelope mandated for every Digital Product Passport. Product-specific rules can require a narrower or richer set. The model here is therefore an architecture and acceptance guide, not a universal legal schema.
The handoff question also starts after an important earlier question has been answered. If you do not yet know who can establish the fact, what evidence can support it or at what scope it becomes true, start with where a product fact becomes true.
Jump around this page
- Direct answer
- The minimum evidence envelope
- Value, evidence and transport are separate layers
- Identifier and scope joins decide whether the evidence appli
- Credentials, EPCIS and data spaces solve different parts of
- A receiver-side handoff checklist
- The handoff does not replace actor-specific duties
- What would change this page
- Sources
The minimum evidence envelope
A downstream business should be able to understand the assertion without reconstructing the supplier's inbox, technical file or source system. In practice, we would preserve nine things around a consequential product fact.
| Envelope element | What the receiver needs to know |
|---|---|
| Value or state | The actual value, statement or status being handed over, including the unit where relevant. |
| Definition or method | What the field means and how the value was measured, calculated, classified or declared where that changes interpretation. |
| Subject and scope | The product, model, variant, batch, item, facility, period or other scope the evidence actually covers. |
| Evidence or source | The document, record, dataset, event or other evidence object that supports the assertion. |
| Issuer and holder | Who made or issued the assertion, and who currently holds or controls access to the supporting evidence where those are different parties. |
| Identifier joins | The identifiers that bind the evidence to the relevant product and, where needed, its batch, item, facility, order or event. |
| Version and effective date | Which version is being relied on, when it became applicable and any date needed to interpret its currency. |
| Access status | Whether the receiver can inspect the evidence directly, needs permission or can only rely on a controlled reference. |
| Change state | Whether the assertion or evidence is current, superseded, expired, revoked, corrected, disputed or otherwise subject to change. |
The list is deliberately technology-neutral. A PDF can carry all of that context. An API response can lose it. A signed credential can carry it while still containing a weak underlying claim.
The envelope also does not decide how persuasive a supplier's evidence is. If that is the unresolved question, the next job is assessing supplier evidence. This page is concerned with what must survive once an assertion and its evidence are being handed on.
Value, evidence and transport are separate layers
The easiest way to design a safe handoff is to stop treating the value, the evidence and the transport as the same object.
The value is the assertion you want to reuse. The evidence is why somebody should accept that assertion at the stated scope. The transport is how the value and its evidence context move between organisations. The receiver's governed record is the receiver's decision about whether that incoming assertion can be reused, needs checking or remains unestablished.
A useful flow is therefore:
evidence -> governed assertion -> transport -> receiver validation -> downstream reuse
Each step should preserve the identifiers, scope and version needed to travel backwards as well as forwards. A recipient should be able to start with the downstream value and find the evidence that supports it, not merely discover that somebody else once supplied the same number.
Important distinction: the format is not the evidence. A signature, API, data carrier or interoperable message can protect or move an assertion. None of them makes an unsupported physical or regulatory claim true.
EU DPP infrastructure already makes the transport layer a serious design concern. Commission Implementing Decision (EU) 2026/1736 references harmonised standards covering exchange protocols, identifiers, data carriers, persistence, lifecycle APIs and interoperability. Those standards do not define one category-neutral evidence envelope, and they do not remove the need to bind a claim to the right subject and evidence.
The same separation works in distributed supply chains. NIST's 2026 manufacturing traceability meta-framework describes linking and querying verifiable traceability data across disparate ecosystems without requiring one central repository. The practical implication is useful: evidence can remain distributed, provided the receiver can resolve the relationships that make the assertion intelligible and checkable.
Identifier and scope joins decide whether the evidence applies
A handoff can fail even when the file format is fine: a correct-looking value may be attached to the wrong scope.
A model-level specification does not automatically become a batch fact. A batch record does not automatically describe every item after splitting, repacking or substitution. A facility certificate does not establish that a particular product was made at that facility unless the product-to-facility binding exists.
That is why the envelope needs both scope and identifier joins. The receiver should be able to see the chain that connects the assertion to the thing they are about to reuse it for. Depending on the fact, that might be a product identifier plus model, a batch or lot identifier, an item serial, a facility identifier, an order line or an event reference.
If the destination record is more specific than the evidence, do not silently promote the evidence to the narrower level. The missing binding is itself a reason to stop, ask for confirmation or keep the fact as not established.
Version works the same way in time. Evidence can have been correct when issued and still be wrong for the current revision. Keeping the effective date, source version and change state lets the next business distinguish "was once supported" from "is supported for this product now".
Credentials, EPCIS and data spaces solve different parts of the handoff
Several established and emerging technologies can carry parts of the envelope. They should not be collapsed into one answer.
Verifiable Credentials. W3C Verifiable Credentials Data Model 2.0 is a W3C Recommendation. A credential can make issuer, subject, proof and status information machine-checkable. That is useful for portable evidence, but cryptographic validity does not prove the underlying real-world assertion. The deeper trust boundary belongs with what a verifiable credential actually proves.
EPCIS. GS1 EPCIS / CBV 2.0.1 is a published event standard for visibility data. It is useful when the evidence depends on what happened to identified objects, when, where and why. An EPCIS event is not automatically the source of every static product fact, and the existence of the standard is not evidence of universal deployment.
UNTP. UN/CEFACT's Digital Traceability Events and Digital Product Passport specifications illustrate an emerging pattern that links product, facility, party and evidence references and can use verifiable credentials or an EPCIS profile. As at 10 September 2026, UNTP still describes this work as work in progress / pre-production pilot. It should not be presented as a final universal DPP exchange profile.
Data spaces. A data space can govern discovery, permissions, agreements and cross-company exchange while the underlying product facts remain in different source systems. That can be valuable where evidence is permissioned or distributed. It does not turn the data space into the source of truth. The architecture question belongs with data spaces for cross-company exchange.
Files, spreadsheets and APIs can also be legitimate handoff mechanisms. The deciding question is not whether the transport looks sophisticated. It is whether the receiver still gets the context needed to interpret, verify and challenge the assertion.
A receiver-side handoff checklist
Before reusing an incoming product fact, ask seven questions.
- What exactly is being asserted? Check the value, unit, definition and method where relevant.
- What does it apply to? Confirm the product, model, variant, batch, item, facility, period or other scope.
- What supports it? Keep a resolvable evidence or source reference, not only the extracted value.
- Who stands behind it and who holds the evidence? Do not assume the sender, issuer, manufacturer, laboratory and evidence holder are the same organisation.
- What binds it to this product? Check the identifier joins rather than matching on a similar product name or description.
- Is it still current and accessible? Check version, effective date, access state and any expiry, supersession, correction or revocation signal.
- What happens if it conflicts? Preserve the incoming evidence and the disagreement. Do not erase provenance merely because a downstream system needs one display value.
A receiver does not have to copy every upstream document into its own master system. It does need enough governed context to explain why the value was accepted, rejected or left unresolved. That is what turns evidence portability into a controlled reuse decision rather than simple data copying.
The handoff does not replace actor-specific duties
This architecture does not tell every actor which documents the law requires them to obtain. Those duties depend on the applicable product and role. If the practical question is what an EU importer should obtain and verify from the manufacturer, keep that legal and operational detail with importer upstream evidence duties.
Nor does a good envelope guarantee supplier cooperation. Evidence may remain private, permissioned, incomplete or unavailable. The envelope helps preserve truth about those states. It must not be used to infer a missing supplier, facility, batch, origin, lineage or environmental fact.
What would change this page
A binding horizontal DPP interoperability rule or final common exchange profile could establish a materially different minimum evidence envelope. Product-specific rules can also require fields, access controls or evidence relationships beyond this generic model.
UNTP finalisation would warrant another review if it materially changes the relationship between product passports, conformity credentials, traceability events and evidence references.
Source-as-at: 10 September 2026.
Sources
-
Delegated act
Does this reach your products?
Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.