Transparency Graphs

info

Please note that this content is under development and is not ready for implementation. This status message will be updated as content development progresses.

Overview

This page covers one of the most important topics in the UNTP architecture, namely the representation of real and complex n-tier supply chains as digital twins called transparency graphs. We will cover:

• What is a transparency graph and why it matters?
• How to find the data for the graph?
• How to process the data to create the graph?
• How to deal with practical issues like data confidentiality and actors who have not yet implemented UNTP.
• How to use the graph to pinpoint risks or non-compliances?
• Some hands-on technical examples to guide your own implementations.

What is a Transparency Graph?

A transparency graph is a digital twin of your value chain. It comprises a set of facilities (eg manufacturing plants, mine-sites, farms, etc) that are linked by the exchange of products and materials. The output products & materials of one facility are the input of others, thereby building the "graph" of relationships that represent your supply chain. Each facility and product include conformity claims such as product safety, carbon footprint, waste management, labour rights and so on. Some of the claims are backed up by independent assessments that add trust to the claims. The illustration below shows a simplified picture of a critical minerals to electric vehicle / data centre computer transparency graph. The diagram illustrates how each facility transforms input products and materials to make outputs that are shipped to the next facility. It also shows (in green) how UNTP works across sectors with the example of leather as an agricultural by-product making it's way into automotive upholstery.

Of course the diagram above is simply a conceptual illustration. In the real world, your transparency graph will be much more dynamic and likely much larger. That's because, in the real world, most facilities have many more suppliers and many more customers than can be shown in this illustration. And this is a key reason why all this must be digitalised if it is to work at scale. There is just too much data for humans to handle every item cost effectively. A digital twin of an organisation's supply chain allows efficient focus on what matters, easily answering questions like:

• Where are the gaps in my transparency graph (eg non participating suppliers) - so I can request that they adopt UNTP and publish credentials.
• Where are there important conformity claims that do not have evidence of reliable independent assessments?
• Where is there an excess of un-structured and un-verifiable data that I should push for uplift to UNTP credentials?
• Which parties have not attached verifiable evidence of identity from an authoritative source?
• Which parts of my supply chain include conflict zones or locations at risk of political disruption
• and so on.

In essence the transparency graph is a compliance and risk assessment tool that allows organisations to focus their limited resources on the parts that matter.

Finding the data for your transparency graph

The approach to finding the UNTP credentials that carry the information for the transparency graph is simply stated - just follow the product and facility identifiers to find relevant UNTP credentials like Product Passports (DPP), Facility Records (DFR), Conformity Credentials (DCC), and Traceability Events (DTE).

Following (resolving) identifiers

UNTP provides a simple, consistent and repeatable way to discover data about a product or facility given an identifier of that product or facility. The technical details are described in the Identity Resolver specification but, for the purposes of this discussion, the reader can assume that identifiers are signposts to data. The process works as follows:

• Find an identifier - could be a barcode on a box or some data in a document. The identifier might already be a URL (eg a QR code) or it could be a simple identifier (eg a linear barcode) in which case there is a simple way to construct a URL from the identifier.
• Get a list of available data - the URL points to an Identity resolver which returns a list of available data about the identified thing. It's important that one identifier returns multiple data sets because you don't want to have to put dozens of barcodes or QR codes on products.
• Choose the UNTP credentials from the list - The list of available data should include one or more UNTP credentials. Get each one and you are ready to add them to your transparency graph.

Note that:

• The process is independent of identifier scheme. The ID could be a GS1 identifier, or a national facility identifier, or even one you created yourself (a DID).
• The process is recursive. You might start with a product ID, get the DPP, find the "manufactured at" facility ID in the DPP, and use the facility ID to get the DFR. And so on.

The credential types you'll find

UNTP allows any arbitrarily complex value chain to be described with a simple repeating pattern of four credential types. These are described in detail in the specification pages.

The reader may wish to refer to the conceptual data model of each credential shown in the diagram above when reading the sections below.

Finding facility records

The Digital Facility Record (DFR) contains details about a facility such as a manufacturing plant, a refinery, a mine-site, or a farm. It also includes an ordered list of claims about facility performance such as waste management practices, annual emissions, an fair work practices. It is issued and signed by the facility operator.

The diagram shows how each actor in the value chain publishes a digital facility record to any location of their choosing (eg their website) and adds a link to the facility record to the identity resolver link-set. This allows any other actor in the value chain (typically the customer of the facility) to get the facility record by resolving the facility ID. The example shows many different types of identifiers. It should be noted (although not shown in the diagram) that a given facility may have multiple identifiers (eg a GLN, a national ID, an OSH ID, and so on). All of them can be resolvable and can point to the same digital facility record. Just like there can be many signposts to a city on different roads but it's still the same city.

Finding conformity credentials

The Digital Conformity Credential (DCC) is an independent attestation about one or more products or facilities. It issued by an authorised body against a formal conformity scheme, regulation, or standard. It includes one or more assessments such as labor rights, emissions intensity, or product safety. Each assessment is made against well defined criterion drawn from the scheme such as measured tensile strength for construction steel vs minimum required tensile strength.

Any independent conformity credentials about the facility are discoverable in exactly the same way as the facility records. The DCC would simply be another available link in the link-set. The Digital Facility Record itself may also embed URL links to relevant DCCs about the facility. This is not necessary so long as the DCC is included in the identity resolver link-set - it's just like having another signpost to the same credential. In UNTP you can reference the same credential in as many places as you like, that just makes it easier to find.

Finding product passports

The Digital Product Passport (DPP) contains details about a product or material (at model, batch, or item level) such as a battery or a consignment of copper concentrate. It also contains an ordered list of claims about product conformity including product safety, material origin, recycled content, product carbon footprint. It is issued and signed by the product manufacturer or material producer.

The diagram shows the same architecture as described previously for the discovery of facility records and conformity credentials about the facility. The only difference is that the identifier is a product model/batch/item identifier not a facility identifier. Similarly, conformity credentials issued at the product conformity level are discoverable in the same way - either as a link in the link-set or as a reference in the DPP.

For bulk materials upstream, material identifiers tend to be at the consignment (shipment of bulk commodity) or batch level. As we move downstream we start to see specific product serial numbers for a battery or a VIN number for a car. Nevertheless they all work the same way to resolve to product information like DPPs and DCCs.

Finding and following traceability events

The Digital traceability Event (DTE) describes an industrial or commercial process such as the manufacture of goods or the shipment of goods. There are five event types but the most common three events used for UNTP are

• The transformation event which lists the product or material identifiers that are the input to a production process and the product or material identifiers that are the output. For example bulk cotton in and woven thread out.
• The object event (shipping) which lists the products or materials that move from a source facility to a destination facility. For example a consignment of copper concentrate from mine-site to smelter.
• The object event (repairing) which describes an activity performed on a list of product or materials. Such as a post-sale repair event on an EV battery.

Traceability events are usually issued by the product manufacturer / material producer. In some cases, authorised third parties may issue such events (eg for the battery repair).

The DTE is discovered in the same way as other UNTP credentials - by including a link to it in the link-set abotu the identified product or facility. But unlike other UNTP credential types, the DTE links entities through the supply chain by defining inputs or sources for a given output product or destination facility. In the diagram, we see for example the DTE issued by the Manufacturer of the battery that will list the input materials such as copper foil used to manufacture the battery. This means that the OEM that has purchased the battery can use the battery ID to find the battery transformation DTE - and then inside that DTE find the ID of the copper foil and thereby find the DPP for the copper foil.

Because DTEs reveal upstream supply information they can be commercially sensitive. We describe some ways to handle this commercial sensitive in the upstream supplier confidentiality section.

Creating your transparency graph

Having discovered a bunch of credentials that describe your value chain as described in previous sections, the next step is to use them to create your linked-data transparency graph as a digital twin of your value chain. In reality this is an ongoing process as new or updated credentials are found, they are added to the graph.

UNTP is designed with this task front-of-mind so it is actually very simple. Every UNTP credential is built using JSON-LD (the "LD" stands for "Linked Data") so the credentials are already natively graph ready. Just load them to your preferred graph database and the linked data model will emerge.

UNTP links entities not credentials

One very important concept to grasp is that the transparency graph is not a graph of linked credentials like DPPs and DCCs. it is a linked-data graph of the identified entities found inside the credentials. So, in the diagram below, the graph is created from the entities (dark blue ellipses) and relationships between them. The UNTP credentials are just containers for these entities and are shown as lighter coloured shading around the key entities. Please note that the diagram below is a conceptual model designed to facilitate understanding, not a rigorous UNTP ontology, which is a little more complex.

The diagram illustrates many of the key ideas in UNTP. For example:

• That products are made at facilities and assert a number of performance claims which are made against criteria defined by recognised conformity schemes.
• That an attestation is issued by an authorised party and includes a number of conformity assessments about either products or facilities. The assessments are also made against criteria defined by authoritative schemes that depends on recognised standards.
• That all parties have one or more authoritative registered identities governed by a registrar such as a national business register.
• That a manufacturing or service process happens at a facility and may consume input products to create output products.

These are the types of entities and relationships that will appear in your transparency graph when you load UNTP credentials.

Loading a credential to the graph

As stated earlier, UNTP credential are graph-ready by design so loading them into your graph database is simple. That's because every entity that will become a node on the graph always has a "type" (from a controlled UNTP list - like "assessment"), a globally unique "id", and a human readable "name". And the entity will always be in a context that defines it's relationship to other entities.

This is best explained via a small snippet of a UNTP digital facility record credential.

...
"facility": {
      "type": ["Facility"],
      "id": "https://someregistrar.com/facility/9468240000012",
      "name": "Copper Mine 7",
      "registeredId": "9468240000012",
      "idScheme": {
        "type": ["IdentifierScheme"],
        "id": "https://facilities.someregister.com",
        "name": "Global Facility Number"
        }
      },
      "conformityClaim": [
         {
           "type": ["Claim"],
           "id": "https://somefacility.com/claims/ABC12345",
           "name":"environmental mgt system",
           "assessmentDate": "2025-07-15",
           "assessmentCriteria": [
             {
               "type": ["Criterion"],
               "id": "https://some-conformity-scheme/criteria/ems-2017",
               "name": "EMS Standard 2017",
               "description": "Participants shall minimize environmental impact through compliance with regulations, effective management of resources, and reduction of emissions and waste.",
               "conformityTopic": "environment",
               "status": "active"
             }
             ],
           "conformance": true
         }
        ]
...

There are four typed entities in the snippet and so it would create four nodes in a graph with defined relationships between them:

• A facility node with ID https://someregistrar.com/facility/9468240000012 and name Copper Mine 7. The facility has two relationships:
  • an idScheme relationship to an identifierScheme node with ID https://facilities.someregister.com and name Global Facility Number
  • a conformityClaim relationship to a claim node with ID https://somefacility.com/claims/ABC12345 and name environmental mgt system
• The claim would also have a assessmentCriteria relationship to a Criterion node with id https://some-conformity-scheme/criteria/ems-2017 and name EMS Standard 2017

Which might render on your graph something like this

The more credentials you add to your graph, the more it starts to provide a meaningful digital twin of your real supply chain. Since all UNTP data is digital and graph native, the entire process of discovery, load and analyse can be automated.

A couple of important notes:

• Often a credential will contain an entity that is already a node in the graph. For example you load a DFR, which creates a facility node (eg with id https://someregister/facilities/5558880000030). Then you upload a DPP that has a "producedAtFacility property which is of type facility and has the same id https://someregister/facilities/5558880000030. In this case of course you do not create a new facility, you just create a link from the "product" node to the "facility" node with name "producedAtFacility".
• Sometimes a relatively empty new node is created - for example because you find a "assessedFacility" in the "assessment" object of a DCC - so you create a new node with that facility id (assuming it doesn't exist already). Then later on you find a DFR for that same facility. In this case you have new data about an existing node - so you create a new relationship AND update that existing node with all the new data.

So the general rule is - when you find a typed and identified entity anywhere in a credential:

1. If the entity does not already exist, create it.
2. If the entity already exists, add any new properties.
3. Create a link from the containing entity to the referenced entity using the property name of the contained entity.

All this means that no dedicated code is needed to process each version of each UNTP credential. They can just be uploaded to the graph with the same simple logic.

Practical issues

The preceding discussion assumes an ideal state where everyone has adopted UNTP and is willing to share their upstream supplier information. Of course that does not represent the real world.

• In the early stages of UNTP adoption there will be few digital credentials and a lot of unstructured data because most supply chain actors will not have implemented UNTP.
• Most supply chain actors will want to share different data sets with different types of consumers. For example
  • A DPP in english with claims against US regulations for the american market.
  • A DPP in french with claims against EU and French regulations for the French market.
  • Extra data in DPPs that are for market surveillance authorities only and not for the general public.
• As time progresses, the market may demand more and more transparency from suppliers, but initially there will be considerable reluctance to share supply information with customers.

Dealing with actors who have not implemented UNTP

For supply chain participants that have not yet implemented UNTP, their supply chain data will be in any format of their choosing - typically PDF documents. The approach to add such data to your transparency graph is to first transform it into a UNTP linked data structure. The best tool to do that at scale is a large language model (LLM). The diagram shows a case where the min-site and the refiner have not implemented UNTP and are producing PDF documentation. To deal with that, the smelter and fabricator are using an LLM to transform the PDF data before updating their graph.

There are some challenges with this approach that can be mitigated with careful implementation.

• Entity matching. UNTP depends on globally unique identifiers to link data. A PDF document might refer to a facility as Copper mining facility seven when the same facility is known to the graph as ID https://someregister/facilities/ 5558880000030 and Name Copper mine 7. THis would lead to a duplicate facility being created without links to other important data. However, LLMs are excellent at matching similar data so implementers should follow GraphRAG best practices and first ask the LLM to extract and match entities, then transform data using matched entities.
• Discovery While UNTP credentials are always reliably discoverable from identifiers, which also means they can be maintained easily by checking for updates. However this Identity Resolver (IDR) capability need not be limited to discovering UNTP credentials. it can also be used to make things like PDF product or facility data consistently discoverable. So a strong recommendation to supply chain stakeholders is that there is value in simply making your existing data discoverable via IDR even it you have not yet implemented UNTP credentials.
• Integrity when unstructured versions of important documents such as conformity certificates are used, there is a greater exposure to fraud and counterfeiting. It is very easy with modern AI tools to make very compelling fakes. But AI cannot generate valid cryptographic signatures. Therefore implementers should plan to transition from pdf documents to digitally signed credentials to protect themselves from risks of fake data. However, placing your unstructured data behind an IDR also provides some risk mitigation because only the genuine owner of an identifier can update their data records in the register - so pulling product or facility data via an IDR at least ensures that the data is genuinely published by the identifier owner.

In the diagram above, we see that the mine-site is passing unstructured data to the smelter via some un-managed channel. So the smelter needs to manually ask for updates and cannot be sure that the data is really from the mine-site. However the refiner, although still exchanging unstructured data, is doing so through an IDR. So the fabricator can be confident that it is genuine refiner data and can automate the discovery and update process.

Dealing with different consumer requirements

It is very common that manufacturers and brands want (or need) to provide different product & facility data sets to different consumer roles. For example:

• A border authority or market surveillance authority may require access to data that is not for the general public.
• Specific roles such as recycling facilities may require access to disassembly information or toxic chemical treatment information that is not generally public.
• A long lived manufactured product may need to manage post-manufacture repair or service information about the product - so the service provider needs to update the product record.
• Even public data may need to be made available in multiple different languages and/or to meet different national regulatory reporting requirements. For example if USA and EU both require PDF (product carbon foot-print) data but define different calculation rules.

The diagram above show examples of how UNTP meets these requirements.

• authorised disclosure The mine-site publishes a public product passport for a consignment of concentrate. However regulatory authorities demand extra data such as detailed evidence of PCF calculations for Carbon border adjustments. In this case the mine-site publishes two DPPs and both are discoverable from the same Identity resolver, but one of the credentials is encrypted. The Regulator presents an identity credential proving their authorised role and the IDR or mine-site system returns a decryption token.
• buyer disclosure/actions The refiner also publishes two product passports, one is public and the other contains information only intended for the legitimate buyer of the specific batch of cathodes. But because there may be many traders between refinery and fabricator, the refinery has no a priori knowledge of which fabricator will ultimately receive the cathodes. In this case the decryption token is attached to the physical shipment of goods - so only the fabricator that receives the inbound shipment of cathodes can decrypt the confidential data.
• Consumer context. The battery manufacturer sells the same battery into UK and French markets. The manufacturer publishes two public DPPs, one in english and with information about UK regulatory compliance, the other in french and with information about France/EU regulatory compliance. The IDR is aware of the location of the requestor (http header information already carries this data) so, by scanning the same QR code, the UK consumer sees the UK DPP and the French consumer sees the French DPP.

Details on encryption and decryption of confidential data in credentials are in the Decentralised Access Control specification. Details on returning multiple credentials and defaulting to the correct user context are in the Identity Resolver specification.

Dealing with upstream confidentiality

There is a general pattern of "one up, one down" disclosure in value chains. That is an actor will share their product data with their customers and expect to receive product data from their suppliers. But they will often be unwilling to share the data from their suppliers with their customers (two steps in the chain not one) because it may reveal information the is considered to be commercially sensitive. For example, a smelter turns copper concentrate from a mine into slabs of copper blister. The smelter sells blister to a refiner that wants proof that the source copper is from a CopperMark certified mine. But the certificate issued to the miner and contains the mine-site information. So if the smelter passes the CopperMark certificate to the refiner, they are revealing the identity of their supplier to their customer.

Whilst it is technically feasible to use zero-knowledge proof and selective disclosure technologies to hide data in credentials without breaking their cryptographic integrity, there are two problems with relying on this approach.

• first, the technologies are not in widespread use so it becomes possible that a redacted credential issued by one party is not readable at all by the next party.
• second, and more importantly, for the refiner to trust the smelter's claims, they need evidence of total copper concentrate mass-balance to have proof that the smelter is not re-using a certificate from one mine-site to represent all it's output. So, data that is sufficiently redacted to hide supplier information is often unusable for validation.

Therefore the approach recommended is for each actor to make a choice

• either provide transparency information about your supply to your customers.
• or provide the same transparency information to an independent auditor and pass the resulting attestation to your customers.

In terms of UNTP implementation, this means you either pass DTE transformation events to your customers and let them make their own assessments, or you pass them to an auditor to assess and then give the results of the audit to your customers.

The diagram shows how this might work for the smelter and the fabricator in the supply chain. In this model, the OEM can reach back from battery manufacturer to fabricator but no further. Similarly, the fabricator can reach back to the smelter but no further. However, both can access an independent audit that does attest to the requirements of the customer.

Verifying Transparency Graphs

Although transparency graphs are constructed from data in verifiable credentials, it does not follow that if every individual credential is valid then the graph is verified.

Trust Chains

Consider the scenario where GHG emissions of a product result in a carbon border adjustment that must be paid. In such cases, the potential for fraud is significant, as some manufacturers might falsely claim low GHG emissions in their digital product passport. To combat this, verifiers must be able to construct a chain of trust. For example

• A manufacturer issues a declaration in a UNTP Digital Product passport (DPP) that states an emissions footprint for a given product ID. If the verifier trusts the manufacturer then this may be sufficient. But often a third party attestation is needed.
• A third party Conformity Assessment Body (CAB) issues an attestation as a UNTP Digital Conformity Credential (DCC) about the same product ID that confirms the emissions footprint. If the verifier knows and trusts the CAB then this may be sufficient. But there are thousands of CABs and so it is very possible that the verifier does not know or trust the specific CAB.
• A national accreditation authority issues an endorsement as a UNTP Digital Identity Anchor (DIA) which states that the CAB is accredited to issue certifications under a recognised scheme such as the GHG Protocol. The number of accreditation authorities is only a little larger than the number of countries, so verifiers only need a short list of accreditation authorities ("trust anchors") in order to trust the chain from product manufacturer -> CAB -> national authority.
• Most national accreditation authorities are members of a global association such as ILAC. If ILAC were to issue a credential attesting that national authority is a member then there is a chain of trust from manufacturer -> CAB -> national authority -> ILAC.

Ultimately, verifiers need only maintain a very short list of ultimate trust anchors. In general, all these actors in the trust chain already exist and have well managed governance frameworks. The verifiable credential and transparency graph technologies are not creating new trust models, they are just making existing ones digital and verifiable at scale.

Graph verification rules

The validation rules for a given transparency graph that represents a specific actor's value chain are of course up to the the specific actor. However there is likely to be a tiered set of re-usable rules that would make life easier for each actor.

• UNTP core validation rules. There is a core subset of rules (eg that claims are verified by assessments, that identities are anchored, etc) that will be common to all industry sectors and all geographies.
• On top of the UNTP core rules, there will be industry specific rules that apply to specific UNTP extensions such as Which specific sustainability schemes are trusted, what identity schemes and anchors are preferred, etc.
• As well as industry level common rules, there will be geography specific rules that will typically map to national regulations. These could usefully be defined consistently by each regulator.
• Finally there will be rules that reflect the specific requirements of individually organisations.

UNTP and extensions will make these validation rules public and re-usable so that specific implementers need only consider whether they wish to add any organisation specific rules.

UNTP graph validation rules.

TBA - write initial rules as psuedo-code here.

Working Example

TBD - put description and links to a sample transparency graph here.