How Do Companies Exchange Product Carbon Footprint Data? PACT, Versioning and Verification
How to exchange Product Carbon Footprint data without losing method, identity, version or assurance context, with PACT v3 as a current implementation example.
A product carbon footprint becomes much more useful when another organisation can receive it without losing the method, product identity, version or assurance context that gives the number meaning. This page explains the exchange layer, using PACT v3 as a current example rather than treating it as an EU Digital Product Passport requirement.
Direct answer
Companies can exchange Product Carbon Footprint (PCF) data reliably when the carbon result travels as a governed data record, not as a number copied into a spreadsheet or feed.
PACT separates two jobs that are easy to blur. PACT Methodology v3 sets rules for calculating and reporting cradle-to-gate PCFs. PACT Technical Specifications v3.0.3 define a machine-readable data model and REST API for exchanging those footprints between systems.
That means a useful exchange record needs more than kg CO2e. It needs enough product and footprint identity, calculation context, time and data-quality context, lifecycle/version information and verification metadata for the recipient to understand what the figure represents.
PACT conformance is an interoperability claim. It does not by itself certify that the underlying footprint calculation is correct, and PACT is not a mandatory EU DPP exchange protocol.
Navigate this page
- Overview
- Direct answer
- The carbon number is only one field
- PACT standardises two different layers
- What needs to travel with a Product Carbon Footprint
- What happens when the PCF changes
- Conformance, verification and assurance are not synonyms
- What named implementations show
- What this means for governed product data
- Practical checks before exchanging PCF data
- What would change this page
- Sources
The carbon number is only one field
A carbon figure can be perfectly readable to a person and still be a weak data object.
Suppose a supplier sends 8.4 kg CO2e. Before a recipient can reuse that figure confidently, it needs to answer questions such as:
- Which product does the number describe?
- What quantity or declared unit does it relate to?
- Which methodology and boundary produced it?
- What reporting or validity period applies?
- Which data were primary, secondary or otherwise qualified?
- Has the footprint been independently verified, and if so, what was covered?
- Is this the current footprint or an earlier version?
- What should happen when a revised footprint arrives?
Those questions are why understanding what an environmental figure actually counts comes before exchange mechanics. The calculation result and its boundary still matter. Exchange standards do not repair a poor calculation.
The additional problem is continuity. Once the figure leaves the calculator and moves through procurement, supplier portals, product-data systems or customer APIs, its meaning has to survive the move.
PACT standardises two different layers
PACT's current architecture is useful because it makes the calculation/exchange distinction explicit.
| Layer | What it does | What it does not prove |
|---|---|---|
| PACT Methodology v3 | Defines methodology and reporting expectations for cradle-to-gate PCFs | That two software systems can exchange the record correctly |
| PACT Technical Specifications v3.0.3 | Defines the product-footprint data model, API behaviour and lifecycle semantics for interoperable exchange | That the underlying calculation is substantively correct or independently assured |
| Verification information | Records assurance context such as coverage, provider and completion information | That the exchange endpoint itself is conformant, or that every recipient should accept the assurance |
The technical specification itself distinguishes the OpenAPI/schema requirements used for machine interoperability from methodology reporting rules. That is a useful design principle beyond PACT: calculation rules, exchange rules and assurance claims are different controls.
Treating them as one status creates avoidable ambiguity. A technically valid payload can carry a weak footprint. A well-assured footprint can be sent through a non-PACT mechanism. A recipient needs to know which claim is being made.
What needs to travel with a Product Carbon Footprint
PACT's data model is more detailed than the simplified map below, but the operational idea can be reduced to six information layers.
| Information layer | What the recipient needs to know | Why it matters |
|---|---|---|
| Result | The PCF value and relevant unit/context | The numerical result being exchanged |
| Calculation context | Method, boundary/scope, period and relevant data-quality information | Prevents the number being detached from how it was produced |
| Product identity | Which product or product identifiers the footprint relates to | Stops one footprint being reused against the wrong product |
| Footprint identity | A unique identifier for the footprint record itself | Lets systems refer to a specific calculated record |
| Lifecycle and lineage | Whether the footprint supersedes earlier records and how versions relate | Preserves historical truth when the footprint changes |
| Verification context | What was verified, by whom, when and under what stated context | Keeps assurance explicit instead of implied |
The key distinction is between product identity and footprint identity. A product can keep the same commercial identity while its footprint changes because inputs, activity data, methodology or calculation quality change. The product is not necessarily new. The footprint record is.
That is why a PCF should be governed as a derived product-data object with its own lifecycle.
What happens when the PCF changes
PACT v3 does not model a revised footprint as a silent edit to the old value.
When a PCF changes, the specification uses a new footprint identifier. Earlier footprint records can be deprecated and related to the new record through preceding footprint identifiers.
In practical terms:
- Product X has footprint record
PF-1. - The business recalculates the footprint after better supplier data becomes available.
- The new calculation becomes
PF-2. PF-2can point back toPF-1as a preceding footprint.PF-1can be deprecated rather than rewritten as if the new result had always been true.
This is a concrete example of the wider rule covered in when to overwrite, version or create a new product record: changing a governed fact is not the same thing as changing the product's identity.
The exact PACT lifecycle model is not a universal DPP rule. Its value here is that it makes record lineage explicit for a consequential derived value.
Conformance, verification and assurance are not synonyms
This is the distinction most likely to be lost when PCF exchange is reduced to a badge.
PACT conformance
The technical specification defines conformance for host systems against its normative API requirements. That is about whether systems implement the exchange behaviour expected by the specification.
It is an interoperability statement.
Methodology reporting
PACT Methodology v3 sets reporting expectations for the PCF itself. The technical specification can carry information needed to support those reporting rules.
That is about the content and context of the footprint.
Verification
PACT also models verification information separately. The data can describe matters such as verification coverage, provider, completion date and the stated verification context.
That is an assurance statement.
None of those should be silently upgraded into another. In particular, a PACT-conformant exchange does not mean the carbon calculation has been independently verified or is factually correct.
If you need the wider question of who checks a DPP claim or product fact, keep that with the evidence and assurance layer.
What named implementations show
A specification can define interoperable exchange without making supplier participation automatic.
WBCSD's 2026 Fujitsu case study describes engagement with more than 60 suppliers as part of its PACT implementation, including follow-up and enablement work. Fujitsu had already announced operation of PACT-compliant PCF data exchange in 2024.
The useful lesson is not the supplier count by itself. It is that a common protocol does not remove the operating work around supplier data, onboarding, responsibilities and process change.
BASF's PACIFIC implementation provides a second bounded example. BASF describes exchanging PCF data through the Catena-X automotive ecosystem. That demonstrates that common PCF exchange rules can be put into production within a sector data ecosystem.
It does not establish Catena-X as the universal architecture for PCF exchange. Sector governance, partner requirements and system architecture still matter.
The PACT Data Exchange Sandbox points in the same direction from another angle: manual, spreadsheet and email-based exchange can persist even when an interoperable technical model exists. Standards reduce translation friction. They do not remove every commercial or organisational dependency.
What this means for governed product data
For a sustainability or product-data team, the useful unit is not simply carbon_footprint = 8.4.
A governed PCF record should let you establish:
- what product the figure belongs to
- what method, boundary and period produced it
- which version of the exchange specification it follows
- which footprint record is current
- which earlier records it replaces
- what evidence and verification context sit behind it
- which downstream systems or partners have received which version.
That is the point at which a PCF becomes reusable product data rather than a value pasted into a destination.
It also explains why one calculated fact may need to be transformed for several systems without becoming several competing truths. The governed record keeps the identity, evidence and lineage. Each destination can then receive the representation it actually needs. The broader pattern is covered in Product Data Across EU Systems: What Can Be Reused and What Must Stay Separate.
PACT is a strong current example of that architecture. It should not be mistaken for a legal requirement that every EU Digital Product Passport must adopt.
Practical checks before exchanging PCF data
Before treating a supplier PCF as reusable, check five things:
- Identity: can you tie the footprint to the right product and the right footprint record?
- Meaning: can you establish the method, boundary, period and relevant data-quality context?
- Version: can you tell whether the footprint is current, superseded or part of a lineage?
- Assurance: can you distinguish verification metadata from exchange conformance?
- Operating fit: can the supplier and recipient actually maintain the exchange process as data changes?
A "yes" to the API question alone is not enough.
What would change this page
This answer should be reviewed if:
- PACT publishes a new major methodology or technical-specification version that changes the exchange or lifecycle model
- EU product legislation formally adopts a particular PCF exchange method for a defined product group
- new independent evidence materially changes what is known about production adoption or supplier-readiness constraints.
As checked on 6 September 2026, PACT Technical Specifications v3.0.3 remain the latest published technical specification.
Where this connects
Related resources this page depends on.
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.