Consultation Feedback for the Version 3 release

[zeitgeist]

Context & Introduction

1. We, as SINE Foundation, were asked to provide input, following a general reach out by PACT to non-PACT Members
2. Our feedback is based on our past involvement in PACT plus our current works with related projects such as iLEAP 1 2
3. Several chapters have improved from V2 and V3 in terms of clarity and quality of explanation. Kudos!
4. Specifically Chapters 6 and 8 are now much easier to follow, and lots of redundancy was removed in the editing process. Good work!
5. We spilt our feedback in two parts: Feedback & Questions, and errata-like findings. Each feedback is scoped by chapter, and where possible, we quote the tech specs
6. It is possible that some quotes we put in here got out of sync. Originally, we collected feedback against this document which was referenced in PACT's email. Later we discovered, that several of the issues raised were already fixed, and henceforth we updated our comments against the latest version (3.0.0-20250325)
7. The content here was copied over from a Notion Doc. there might be spurious formatting issues, apologies for this
8. When we write "you", we mean the PACT team

In summary, congratulations to the PACT Team and the broader community for putting so much effort into the Version 3 release, making reading it a much bigger pleasure than ever before.

This is the first part of our feedback. We will follow up with additional feedback via email as well.

Feedback & Questions

Chapter 4

Consider referencing/cross-linking the Event types (e.g. RequestCreatedEvent ) as a courtesy to readers.

Chapter 4.2.1

This is quite minor:

4. Asynchronously, the data owner will create a PCF or find an existing relevant PCF.

Considering that such a request can return multiple (or no) PCFs, I’d propose to put there

4. Asynchronously, the data owner makes zero or more new or existing PCFs available

Chapter 5.2.4

1. Version 3.x MAY in its internal data model store the version and updated properties. Any incoming minor change will be accepted if incoming.version is higher than existing.version. The updated PCF will be stored, including version and updated properties.
2. Version 3.x MAY choose NOT to store version and updated properties. In that case, any incoming minor change will be accepted if incoming.updated is later than existing.created. The PCF will be stored, making sure the created date/time is set to the incoming updated date/time.

Some clarification questions:

1. Consider clarifying / being more explicit on what is meant withVersion 3.x here. Presumably, a Host system implementing some Version 3 Tech specs is meant?!
2. We do not quite understand what is meant with, for instance, “Any incoming minor change […]”. Is this implementation guidance about some kind of “backwards compatibility” or handling of existing PCFs that were computed with a V2 regime and are now exposed using a V3 implementation?
3. Last, but not least: consider linking to the property definitions as a courtesy to the readers

Chapter 5.3

Consider moving this chapter to Chapter 7 instead.

Chapter 6 – General Feedback 1

You propose a urn:pact:$domain-of-issuer$ syntax there, which effectively means that each identifier falling under urn:pact: is treated equal.

Did you also take into account the following in your consultations [the ADR does not]:

1. I am [some-corp.com](http://some-corp.com/) and add to my PCFs urn:pact:basf.com:buyer-id:$some number$ implying BASF was my customer. In other words, there is no further guidance on the use of domain names. I can essentially pick any one – I think this should be made explicit or at least hinted at that in the future further guidance would be added.
   1. I regard this to be specifically relevant for the examples given, such as [inchi-trust.org](http://inchi-trust.org) examples given that imply a strictness or semantics that is not brought forward but should.
2. A flipside of the “egalitarian” / “all domains are treated equal” approach is that you cannot further evolve or otherwise partition the URN “space” beyond what you specified here, i.e. you’d need to pick a different namespace-id later if you wanted a urn syntax or semantics or “new feature” that does not fit the current scheme.

Chapter 6 – General Feedback 2

Specifically for Product Classification , more guidance, especially forward-looking ones, for implementers is necessary:

1. how are host systems supposed to deal with unknown identifier types, domains etc. (see below feedback for a more critical take on this as well)
2. how are host system supposed to “interpret” classification(s)?
   1. Related: Will there be a recommended list of semantics and encodings soon?
   2. What will this governance look like, how will it evolve etc.?

Chapter 6

Given this situation, organizations must perform laborious and manual “mapping” exercises to map their identifier(s) for a product to the identify their supplier can understand.

[emphasis added]

Probably ‘to an identifier’.

Chapter 6.1

Consider adding more guidance on identifier types that are not part of the current list.

1. e.g. you could take a similar approach as with the filtering syntax, by defining custom identifier types to have an x-$custom-id syntax

Chapter 7.4

1. Some semantics are equivalent (M3-2027 and SHALL-2027), (M and SHALL); please consider reducing the amount of validation rules as an aid to the reader.
2. In the table, some references are made to 2027 . Consider adding more guidance on the semantics of the time-bound rules – i.e. “When” does “2027” apply? Is it scoped by reference period, is it time of PCF calculation, or something different?

Chapter 7.6.1

1. Consider marking properties version and updated as deprecated.
2. Property companyIds has a TODO inside.

Chapter 7.7.2

Regarding the definition for landCarbonLeakage:

Indirect land use change due to carbon stock losses from conversion of native ecosystems to agricultural land to replace food production.

[emphasis added]

Is it possible that the following is meant:

Indirect land use change due to carbon stock losses from conversion of native ecosystems to agricultural land for food production.

Chapter 7.7.2

This is more of a Q for me to understand some intricacies of Carbon Accounting:
The property uncertifiedLandManagementCO2Removals has “equal or greater than zero” semantics, whereas the landManagementBiogenicCO2Removals follows the “less than or equal to zero” semantics. Would you elaborate a bit on this?

Chapter 8 – General Feedback

Consider adding further guidance host system guidance on the PCF “data workflow”, covering:

1. how is a host system supposed to handle updated or new data WRT data recipients with access to it – this is indirectly covered in other chapter but they are either informative only or are only about event processing (i.e. interoperability rather than system internals)
2. how is a host system supposed to work with V2 data recipients? Is it recommended to still implement V2?

Chapter 8.6.3

The exact syntax for filtering on arrays is unclear. Consider adding an example.

Chapter 8.6.4

| 401 | The request is not authorized, the access token is invalid or has expired.
Response body MUST contain a JSON [Error](https://docs.carbon-transparency.org/v3/#elementdef-error) object |
| --- | --- |

[Above is exemplary for the following:] the current specification leaves it open what exactly the error code of the returned JSON Error object should be; i.e. I could return a BadRequest error with 401. Is this intentionally so? Please elaborate.

Chapter 8.6.4

Response code 202 is gone now, however this was still present in the Tech Specs originally distributed for review (https://wbcsd.github.io/tr/2025/#api-action-list-request) – does this mean the 202 code is now gone as a concept? (We would have recommended this otherwise)

Errata-like Findings

PACT Methodology Normative reference

The Normative Reference PACT-METHODOLOGY is still pointing to V2 of the Pathfinder Framework.

Presumably this will be fixed on time of the V3 release?

Chapter 4.1.2, Chapter 5.3

Consider fixing the dangling reference ([#lifecycle] ) – there are more though.

Chapter 6.2.1

This is an international standard for categorizing goods and services. (for wheat)

and

UNSPSC is a global classification system for products and services, often used in procurement. (for desktop computers)

Are the parentheses intended as they are (i.e., lowercase, no period)?

Also, periods are missing from the table on the first two lines.

Chapter 7.3 plus Chapter 7.6, 7.7, etc.

The qualifiers NonEmpty and Unique do not appear to be used in any of the later properties sections.

Chapter 7.4

| (e.g. kgCO2e: kilogram CO equivalent) 

Should probably read '(e.g. kgCO2e: kilogram CO2 equivalent)'

Chapter 7.7.2

E.g. property uncertifiedLandManagementCO2Removals references qualifier M2-2025 which is not defined in above table (although semantics can be inferred from chapter 7.4).