Supply-chain mapping, traceability and chain of custody: what is the difference?
Understand the practical difference between supply-chain mapping, visibility, provenance, traceability and chain of custody, and which capability fits which job.
Direct answer
Supply-chain mapping shows the structure of the chain: the organisations, sites, roles and flows you know about. Visibility is the ability to see relevant information about what is happening within a defined part of that chain. Provenance concerns origin and history.
Traceability connects identified products, materials or lots to records that let you follow them through relevant stages or events. Chain of custody governs how a specified characteristic or claim is carried, preserved or allocated as material or products move through the chain.
Supply-chain mapping, visibility, provenance, traceability and chain of custody answer different questions. Treating them as synonyms makes it easy to buy too much technology, collect the wrong evidence or make a claim your records do not support.
They overlap, but they are not interchangeable. A useful test is to start with the decision you need to make, then ask what relationship the evidence has to preserve.
| If you need to know... | Capability to start with | What it gives you | What it does not give you automatically |
|---|---|---|---|
| Who is in the chain and where material may flow | Supply-chain mapping | A structured view of actors, sites, roles and flows | Event-by-event history of one product |
| What is happening across a defined network | Visibility | Access to relevant status or information within that scope | Complete provenance or proof of a claim |
| Where something came from and what history is recorded for it | Provenance | An origin or history record tied to a defined subject | Continuous tracking through every stage |
| Where an identified object or material has been and what happened to it | Traceability | Linked records across relevant stages or events | Proof that every attached claim is true |
| How a specified characteristic or claim survives transfer, mixing or allocation | Chain of custody | Rules and records connecting inputs, outputs and claims | Independent proof of the underlying characteristic |
The boundaries matter because the evidence burden changes with the job.
Jump around this page
The five terms side by side
Supply-chain mapping describes the network
A map is a representation of the chain. It can identify suppliers, processors, sites, logistics steps and known dependencies. OECD work on lithium and nickel supply chains is useful here because it shows why mapping can improve visibility even where end-to-end traceability is incomplete. Real supply chains are often partial and heterogeneous, so a map can be valuable without pretending every product has a continuous digital trail.
Mapping answers questions such as: who supplies this component, which sites handle it and where are the obvious gaps? It does not, by itself, tell you that this exact lot passed through every mapped node.
Visibility describes what you can see
Visibility is an operational capability rather than a guarantee of completeness. A business may have good visibility over inventory and shipment status but weak visibility over an upstream processor. It may see a certificate without being able to bind that certificate to the product in front of it.
That distinction is useful because “more visibility” can mean many things. Before improving it, define the object, the scope and the decision. Visibility over supplier identities is different from visibility over transformation events or claim evidence.
Provenance describes origin and recorded history
Provenance is about where something came from and the history that can be associated with it. The subject matters. Product provenance, material provenance and evidence provenance are not automatically the same thing.
A document can have clear provenance as a document, for example who issued it and when, while still being poorly bound to the product it is meant to support. Likewise, knowing a product's current supplier does not necessarily establish the origin of every material within it.
Traceability connects an identified subject through records
GS1 traceability work and the NIST manufacturing meta-framework both emphasise linked information across supply-chain activity. The practical requirement is not one giant database. It is the ability to identify the subject and connect relevant records across systems well enough to answer the traceability question.
That may involve product or lot identifiers, locations, business steps and events. The depth can differ by fact. A business may need one-step supplier traceability for one decision and deeper transformation history for another.
If the question is specifically whether a Digital Product Passport legally requires end-to-end tracking, that is a separate regulatory question. The answer is not universally: the applicable product rules determine what data and granularity are required. See what DPP traceability does and does not require.
Chain of custody governs the claim relationship
Chain of custody begins where the important question is not simply “where did this object go?” but “what relationship between an input characteristic and an output claim has been preserved?”
ISO 22095 provides the general chain-of-custody framework. ISO also published dedicated 2026 standards for mass balance and book-and-claim. The model matters because different models support different relationships between physical material, accounting records and the claim attached downstream.
A chain-of-custody system can support the reliability of a claim, but the existence of the system does not itself prove the underlying product characteristic. If you need to distinguish identity preserved, segregated, controlled blending, mass balance and book-and-claim, use the chain-of-custody model comparison.
Which capability fits which job?
Start with the decision rather than the technology name.
| Reader job | First question | Minimum capability to test | Typical failure if you choose the wrong one |
|---|---|---|---|
| Find unknown suppliers or dependencies | Who and where are the relevant actors and sites? | Mapping | Building event infrastructure before the chain is even known |
| Monitor operations | What status do we need to see, at what frequency and for which objects? | Visibility | Calling a dashboard “traceability” when it cannot reconstruct history |
| Establish origin or history | What subject needs an origin/history record and what evidence binds to it? | Provenance | Treating supplier identity as material origin |
| Reconstruct movement or transformation | Which identified object must be followed through which stages? | Traceability | Collecting documents without a reliable join between them |
| Carry a sustainability or material claim | What characteristic is being transferred, mixed or allocated and under which rules? | Chain of custody | Turning an accounting allocation into a physical-content claim |
This sequence also prevents a common architecture mistake: assuming every fact needs the same depth. Product identity, material origin, recycled content and a shipment event can each require a different evidence path.
Traceability is not the same as proof
Traceability can show a chain of records. It cannot make a weak source strong simply because the records are connected.
Imagine a processor records that a lot moved from Site A to Site B. That event may be perfectly traceable. If the recycled-content value attached to the lot came from an unsupported declaration, the event history does not upgrade the declaration into verified physical truth.
The reverse problem also happens. A strong certificate may exist, but if the product is cut, split, repacked or transformed and the resulting child identity is not bound back to the parent evidence, the certificate becomes difficult to reuse safely. The weakness is then the join, not necessarily the document.
What DPP traceability does and does not require
ESPR creates the horizontal DPP framework, but product-specific delegated rules determine the information that must be included and the required granularity. That is different from saying every DPP must contain a complete event history from raw material to sale.
A DPP may depend on upstream evidence without publishing every upstream event. It may expose a fact while the supporting evidence remains elsewhere. It may use model, batch or item-level identity depending on the applicable rule.
So “we need a DPP” is not enough to choose a traceability architecture. First identify the required product facts, their scope and the evidence that must survive downstream. Then decide whether mapping, event traceability, custody controls or some combination is actually needed.
Traceability is also not due diligence
A traceability system can provide inputs to due-diligence work, but it does not replace the legal process of identifying, assessing and responding to risk where a particular regime requires that work. A complete event history can still be missing the risk assessment. A due-diligence process can also rely on evidence that is not an item-level event trail.
For that boundary, see traceability versus due diligence.
A simple decision rule
Use this order:
- Name the subject. Product, material, batch, facility, supplier, claim or event.
- Name the decision. What must somebody be able to decide, check or defend?
- Name the relationship. Network structure, current visibility, origin/history, event lineage or custody of a claim.
- Name the evidence. Which records establish that relationship and at what scope?
- Only then choose the system. Do not let the software label decide the evidence model.
That is the practical difference between the terms. They are not competing maturity levels on one ladder. They are different capabilities that can be combined when the job genuinely needs more than one.
What would change this page
The general ISO 22095 framework is currently published but marked by ISO as to be revised. ISO/CD 22095-1 is under development and is not treated here as final. This page should be rechecked if the replacement general framework is published or if OECD, NIST or GS1 materially changes the terminology used for these capabilities.
Sources
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.