Architecture

info

Please note that this specification is suitable for pre-production pilot implementations.

Overview

The architecture is the blueprint for all the components of the specification and how they work together. It defines the design principles which underpin the UNTP and shows the components working together from the perspective of a single actor and across the entire value-chain. The UNTP is a fundamentally decentralised architecture with no central store of data.

Principles

The architecture principles that guide the UNTP design are

Name	Principle	Rationale
No dependency	UNTP should not require any collaboration or dependency between issuers, consumers and verifiers of DPPs	Imposing such collaboration as a pre-requisite for action in a complex many-to-many ecosystem would essentially stall progress
Unknown verifier	UNTP should not assume that the consumer / verifier of UNTP data is known to the issuer, even when confidential data access is required	In a decentralised architecture with thousands of issuers, it would be impractical to register every authorised verifier with every issuer.
Any maturity	UNTP should not assume any technical maturity for verifiers	DPPs and other credentials must work equally for human and machine verifiers - otherwise an insurmountable complexity of knowing which customer has what capability would be required
Any data carrier	UNTP should work with any widely used carrier of a product identifier — including long-established forms such as 1D barcodes and RFID tags, as well as 2D codes (for example QR and Data Matrix), NFC, and identifiers carried in digital documents — so that both existing and emerging automatic identification practices remain usable	Physical identification infrastructure changes slowly. Uptake should not require manufacturers to re-instrument production lines or abandon carriers already in use, while still supporting resolvable 2D and digital carriers where they are adopted. UNTP aligns with internationally recognised AIDC practice (for example ISO/IEC JTC 1/SC 31 families and ISO/IEC 18975 for encoding identifiers over HTTP) rather than mandating a single regional carrier profile.
Verifiability	UNTP should provide confidence in the integrity and trustworthiness of the data	Without trustworthy data, the value of sustainability claims is reduced - possibly to the extent that the business case for adoption is non viable.
Any conformity criteria	UNTP should not dictate which sustainability, circularity, or other conformity criteria (from standards, schemes, or regulations) a claim or assessment must use; it should make the chosen criteria transparent and mappable so equivalent requirements can interoperate across markets	Costs will explode if every exporter must certify separately to every export market's rulebook. Where criteria are equivalent, mutual recognition is a more cost-effective path.
Action requires value	The benefits of UNTP implementation must exceed the costs.	If not then there will be no implementation

Who this specification is written for

Almost nobody who benefits from UNTP will read it. A smallholder cooperative, a tier-three component maker and a corner shop will issue and verify credentials the way they already make international payments: through software that implemented the standard on their behalf, without encountering the standard itself. Nobody reads ISO 20022 before accepting a card payment.

That is the design assumption, and it decides where cost has to fall. The specification is written for the few thousand software providers, registries and integrators who implement it, so that the millions of supply chain actors they serve do not have to. A requirement that is cheap for an implementer and invisible to an end user is doing its job; one that pushes effort onto the end user has failed, however elegant it looks to a specification reader.

Implementing once means implementing the core once. An extension adds schemas, contexts and vocabulary, and an implementation driven by those artefacts rather than by hard-coded structures can absorb a new one as configuration, so supporting a battery passport or a critical minerals extension does not mean implementing UNTP again. What does fall to each adopter is the business side of an extension, the data gathering, the process change and the stakeholder engagement, and that cost sits outside UNTP's technical scope.

A smaller group does read the specification closely, and for different reasons. Regulators cite it in rules and procurement conditions, conformity scheme owners align their criteria and vocabularies to it, and extension authors build on it for a sector or a jurisdiction. What those readers need is stable terminology, normative statements they can point at, and artefacts that resolve, which is the same discipline that keeps implementation cheap.

Three things follow from the design assumption, and they are the reason the architecture takes the shape it does. Extensions and the governance tree let a sector or a region adapt UNTP without central permission and without breaking interoperability, so adaptation does not become a bottleneck. The specification is published as a website with resolvable machine-readable artefacts rather than as a document, so that implementation can be assisted by tooling rather than read, transcribed and interpreted. And conformance testing with public implementation registers exists because a standard implemented slightly differently by each vendor fails in the field no matter how well it is written.

All three depend on tools that already exist. In a sector or a market where no provider has implemented UNTP, the first mover carries a cost the model otherwise spreads, with no register entry, no published scheme and no peer implementation to build on. That cold start is a barrier in its own right, not a transitional inconvenience, and addressing it is a priority for the period after the 1.0 release.

Machine-readable by design

UNTP has always been meant to be read by machines as well as by people, and two obligations follow from that. The specification has to be implementable without human interpretation, and a credential has to carry meaning that resolves. Both have been implicit since the start; they are written down here because the cost of leaving them implicit is paid by everyone downstream.

A specification a machine can implement. The direct readers are developers, but much of the work is done by software on their behalf: conformance test suites, code generators, schema-driven validators, and the tooling an extension author uses to check that an extension still conforms to the core. More recently an implementer may point an autonomous agent at the specification and ask it to add a product passport to their system. Each of these needs the same thing, which is that the specification be complete in machine-readable form: every schema, context, vocabulary and sample resolvable at a stable URL, every normative requirement stated in text rather than implied by a diagram, and samples that genuinely validate against the schemas they illustrate. Anything an implementer can learn only from a conversation, a slide or a PDF is a cost that no tool can remove, and implementation cost is the main barrier to uptake.

Credentials a machine can interpret. A value whose meaning resolves to a published vocabulary can be rendered in a reader's own language, because the vocabulary carries localised labels where free text carries only the language it was written in. It can be compared mechanically against an equivalent requirement in another framework, which is what makes alignment between ESRS and GRI, or between the EU Deforestation Regulation and a national instrument, something a system can compute rather than a person assert. It can be aggregated across suppliers without someone reconciling spellings, selectively disclosed without losing its meaning, and verified deterministically. None of that depends on who or what is reading.

An autonomous agent is simply the least forgiving reader of the two. It cannot ask a salesperson, will not read a brochure, and has no experience with which to fill a gap, so it drops a term it cannot resolve exactly as a graph does and reports only what it understood. A determination built on dropped terms is confidently wrong, which is worse than no determination at all. That makes agents a good test of whether these two obligations are being met, rather than the reason for them.

This is also where the principles above bite hardest. Unknown verifier and any maturity were written for human readers and business systems, and they already assume a consumer whose identity and capability the issuer cannot know. Nothing special is required for a machine, since the credential that renders for a person through a render template is the same structured data a machine consumes. What changes is only the cost of ambiguity: a person tolerates a free-text classification, a role label that is nearly right, or a unit inferred from context, and for a machine each of those is silent data loss.

UNTP Conceptual Architecture

Our mission is to support global traceability and transparency at scale. To achieve that mission we must not only define the data standards but also solve all the barriers to adoption at scale. That includes how to find the data, how to secure the data, how to understand the data, and most critically, how to realise enduring business value from the data. These are the five pillars of UNTP.

Small-scale tests are possible with any of these pillars missing but scalability to full production volumes is not.

The Data

The data is the heart of the UNTP. Four credential types work together to create a digital twin of a verifiable value chain of any complexity.

• The Digital Product Passport (DPP) is issued by a product manufacturer and carries basic product data together with a set of conformity "claims" that specify product performance against defined criteria. The DPP is essentially a bundle of differentiated value that a buyer can use to choose a preferred supplier. It also provides a statement of material provenance — what materials the product is made from and where they were sourced — to assist with local-content rules and sanctions compliance.
• The Digital Facility Record (DFR) is issued by the owner or operator of a facility such as a mine, farm, processing plant, or recycling centre. It provides facility-level information including geolocation, bulk material and product types, and conformity claims such as emissions footprint and deforestation status.
• The Conformity Credential (DCC) is issued by an independent auditor or certifier and carries one or more assessments of a product or facility against well-defined criteria. When the product ID and criteria in a DCC assessment match a DPP claim, the claim's value is enhanced through independent verification.
• The Digital Traceability Event (DTE) links input products to output products at batch level, enabling provenance tracing through manufacturing processes to discover an entire value chain.

All four credential types are designed to be extensible to meet the needs of specific industry sectors or jurisdictions.

Implements principles: Any conformity criteria — data structures carry claims against any standard or regulation without dictating which to use. No dependency — each actor independently issues their own credentials without requiring coordination with consumers or verifiers.

Finding the Data

We deliberately say "finding" the data rather than "exchanging" the data because a critical principle is that the issuer usually will not know who will ultimately consume it. If you know the identifier of a product, you should be able to get the data about that product — even years after it was created.

• The Identity Resolver (IDR) implements ISO/IEC 18975, providing a standardised way to resolve an identifier (of a product, batch, item, facility, or entity) to a set of links to further information. The IDR works with simple identifiers encoded as 1D barcodes and complex identifiers encoded as QR codes, returning a rich variety of information tailored to the requestor's needs.
• The Verifiable Credentials Profile (VCP) includes a human-readable rendering template so that every UNTP credential is understandable by both humans and machines. The same product scan returns a nicely formatted passport to a person using their phone — or a structured data set to an automated scanner at the factory door.

Implements principles: Unknown verifier — IDR allows anyone with an identifier to find the data without the issuer knowing who will consume it. Any data carrier — IDR works with 1D barcodes, RFID tags, QR codes, Data Matrix, and digital documents. Any maturity — VCP rendering templates make every credential readable by humans with no technology, as well as by machines.

Securing the Data

As the value of sustainability attributes increases, so does the temptation to make fake claims. Without confidence in data integrity, value is diminished. Without confidence that sensitive data is accessible only to authorised parties, businesses will be less likely to participate. UNTP addresses both challenges through tamper-evident, revocable, identity-linked credentials that each actor can disclose according to their own balance of transparency and confidentiality.

• The Verifiable Credentials Profile (VCP) ensures that all UNTP data objects are issued as W3C Verifiable Credentials — tamper-evident, issuer-identifiable, and revocable. The VCP defines a simple, interoperable subset of the broader W3C specifications.
• The Digital Identity Anchor (DIA) links a self-issued W3C Decentralised Identifier (DID) to a known public identity (such as a VAT registration number) through a credential issued by a trusted authority. This gives verifiers confidence that the issuer is who they claim to be.
• The Decentralised Access Control (DAC) encrypts sensitive data with a unique key per item and distributes decryption keys to authorised roles without any advance knowledge of who holds which role. Even if a key is leaked, exposure is limited to a single item. The DAC also allows verified purchasers to update a DPP with post-sale events such as consumption, repair, or recycling. Encryption is optional; see Disclosing the Data.

Implements principles: Verifiability — VCP ensures tamper-evident, issuer-identifiable, revocable credentials. Unknown verifier — public credentials need no registration; DAC distributes decryption keys without advance knowledge of who holds which role. No dependency — no pre-registration between issuers and verifiers is required.

Disclosing the Data

Each actor chooses their own balance between transparency and confidentiality. v1 gives issuers four tools that compose. They answer different questions; they are not a pick-one menu.

Tool	What the verifier gets	Specified in
Public	The whole credential, discoverable from the identifier.	Identity Resolver
Variant	A different complete, signed credential for each role.	Variant-based disclosure
Encrypt	The same bytes; a key only to those who may see them.	Decentralised Access Control
Trusted auditor	An attestation, not the private books.	Privacy-Preserving Verification

Choosing between them. Privacy-Preserving Verification works from what the verifier needs to what the holder can disclose, and covers a case these four tools do not: publishing a commitment to a confidential value without disclosing it.

Encryption is optional. An implementation that publishes public credentials, and variants where different audiences need different claims, can conform without encrypting anything. Encryption is the tool for “same bytes, controlled key” — not a prerequisite for UNTP.

accessRole is disclosure metadata, not authentication. Each link in a linkset says which roles its target is intended for, and the client picks the link meant for it. It is not a query parameter, and it protects nothing by itself. Protection of non-public data is encryption or access control at the storage location. A separate signed variant limits the claims it contains but does not restrict who can retrieve it. See Identity Resolver.

Later, not v1. Cryptographic selective disclosure (for example ZKPs or redacting claims from one signed credential) is out of v1 conformance. Different audiences — including jurisdiction-defined sets such as the four information-access groups in EU Battery Regulation Article 77 — are implemented as variants. Those audiences are an example role set, not a UNTP code list.

Understanding the Data

The UNTP credentials are deliberately simple, but that simplicity hides a world of complexity. In a world of thousands of standards and regulations, each with dozens or hundreds of criteria, how can one claim about social welfare or biodiversity be meaningfully compared to another? The UNTP does not dictate which standards any claim must reference, but it provides the tools to digitalise, unambiguously reference, and harmonise them.

• The Conformity Vocabulary Catalog (CVC) provides a framework to digitalise and unambiguously reference all standards, regulations, and conformity schemes worldwide. It maps sustainability and compliance criteria across different regulatory frameworks and industry practices so that equivalent criteria can be recognised across jurisdictions.
• The Core Vocabulary and the published UN/CEFACT taxonomies provide the shared semantic foundation. Conformity topics classify what is being assessed; performance metrics define how performance is measured. Together they enable alignment and comparability across industries and economies, and Claims and Assessments describes how to use them.

Implements principles: Any conformity criteria — CVC maps criteria across standards and regulations without dictating which to use, enabling mutual recognition where criteria are equivalent.

The Vocabulary section carries the layered picture of how these fit together, and the reference pages behind it.

Valuing the Data

Without sufficient commercial incentive, businesses will not act. Regulatory compliance provides one driver, but broader incentives — corporate sustainability disclosures, reputational risk management, and preferential financial terms — are equally important. UNTP provides tools to quantify these incentives and drive voluntary adoption.

• The Business Case Template (BCT) is a simple template for each role (buyer, supplier, certifier, software vendor, regulator) to build a business case for UNTP investment. Continuously updated with lessons from early implementations.
• The Community Activation Program (CAP) is a business template for community-level UNTP adoption, including financial cost/benefit modelling. Industry-wide coordination unlocks interoperability benefits, shared software costs, and potential funding from governments or development banks.

Implements principles: Action requires value — BCT and CAP exist to quantify the business value of implementation and ensure benefits exceed costs. No dependency — each actor or community can independently build their own case for adoption.

Emergent Value Chain Transparency

UNTP is designed for gradual, independent adoption. There is no need for a coordinated rollout — each actor implements for their own reasons, at their own pace.

When a manufacturer publishes a product passport, value is created immediately: buyers can access verified sustainability data and make informed purchasing decisions. As more actors across the value chain participate — miners, refiners, component makers, assemblers — a verifiable digital twin of the entire supply chain emerges. Critically, this cross-industry traceability does not require collaboration between sectors. A copper miner implementing UNTP for their own regulatory reasons automatically makes provenance data available to a battery manufacturer in a completely different industry. The architecture crosses industry boundaries without requiring coordination between them.

Interoperability Layers

The UNTP architecture maps to the European Interoperability Framework (EIF) four-layer model, ensuring that every layer of interoperability is addressed.

EIF Layer	UNTP Components	Role
Technical	VCP, DAC, IDR	Secure credential exchange, access control, identifier resolution
Semantic	DPP, DFR, DTE, DCC + Core Vocabulary + Core Taxonomies	Consistent meaning of exchanged data
Organisational	BCT, CAP	Industry-specific needs, incentives, community activation
Legal / Organisational	DIA, CVC	Identity recognition across legal boundaries; alignment between conformity rulebooks

The technical layer ensures that credentials can be exchanged, verified, and discovered regardless of the platforms involved. The semantic layer ensures that the data means the same thing to every party. The organisational layer provides the business case and community structures that drive adoption. The legal / organisational layer bridges identity trust and regulatory alignment across jurisdictions. Together, these layers deliver end-to-end interoperability from technical plumbing to legal recognition.