It's advised to use the latest maintained release from the list of maintained releases.
Requirements
Please note that this content is under development and is not ready for implementation. This status message will be updated as content development progresses.
Normative
UNTP Business Requirements
This page summarises the high-level business requirements for UNTP, grouped into seven categories. Each requirement links to the page where its solution is defined.
| Category | Focus |
|---|---|
| 1. Governance Requirements | UNTP is governed openly and transparently, is freely available to all, and is extensible to meet specific industry and jurisdictional needs. |
| 2. Architectural Requirements | UNTP is scalable enough to achieve global implementation at volumes sufficient to have a material impact on traceability. |
| 3. Traceability & Transparency Requirements | UNTP provides the traceability and transparency data each supply chain actor needs to meet due diligence obligations and customer expectations. |
| 4. Trust & Integrity Requirements | UNTP provides data that is trustworthy and resilient to scrutiny. |
| 5. Security & Confidentiality Requirements | UNTP protects the security and confidentiality of supply chain data, letting each actor choose their own balance between traceability and transparency. |
| 6. Compatibility & Interoperability Requirements | UNTP is compatible with existing standards for technology, ESG criteria, and supply chain practices so that implementers can maximise existing investments. |
| 7. Implementation Requirements | UNTP is implementable at the lowest possible cost, gives early implementers a market advantage, and allows the impact of implementations to be tracked. |
1 — Governance Requirements
UNTP must be governed openly and transparently, freely available to all, and extensible to meet specific industry and jurisdictional needs.
| ID | Name | Requirement | Solution |
|---|---|---|---|
| GV.01 | Consensus-driven process | UNTP development MUST follow a transparent, consensus-driven process open to all stakeholders, so that implementers can be confident UNTP will meet their requirements. | Governance |
| GV.02 | Freely available | The UN MUST own UNTP intellectual property, and access and use MUST remain permanently free, so that implementers face no fees or IP infringement claims. | Governance |
| GV.03 | Backwards compatible | New minor versions of UNTP MUST be backwards compatible within the same major version. Each major version MUST remain active and supported for at least two years, so that implementers can rely on the durability of their investment. | Governance |
| GV.04 | Open source | UNTP implementation tools, including reference implementations and test services, MUST be available under open source and royalty-free licensing, so that implementers can minimise their own implementation costs. | Tools & Support |
| GV.05 | Extensible | UNTP MUST define a non-breaking extensions methodology, so that UNTP can be extended to meet specific jurisdictional or industry requirements and implementers of a registered extension can be confident their implementation is interoperable with UNTP core. | Extensions |
| GV.06 | Reusable extensions | Industry and jurisdictional extensions to UNTP SHOULD be governed by an open process and released under royalty-free licence terms, so that extension implementers have the same fees and IP confidence as with UNTP core. | Extensions |
| GV.07 | Implementation register | UNTP MUST provide a mechanism for implementers to register their planned and actual implementations, so that implementers can publish their sustainability commitment and conformant solutions for discovery by a global community of users and customers. | Implementations |
2 — Architectural Requirements
UNTP must scale to global implementation volumes sufficient to have a material impact on traceability. Building on existing industry systems and using the simplest framework that meets the goals makes this achievable.
| ID | Name | Requirement | Solution |
|---|---|---|---|
| AR.01 | Protocol over platform | UNTP MUST define a standard protocol that any business software system can implement, so that every supply chain actor can continue using their preferred software without requiring upstream or downstream actors to agree on shared platforms. | Architecture |
| AR.02 | Decentralisation | UNTP MUST define a decentralised protocol in which data is stored wherever the owner chooses, so that supply chain actors retain control of their data and can monetise their evidence of sustainable behaviour. | Architecture |
| AR.03 | Natural business identifiers | UNTP MUST accommodate existing natural business, product, batch, and shipment identifiers, so that UNTP implementation imposes minimal disruption to existing business processes and can leverage existing business and product registers. | Identifiers |
| AR.04 | Technical maturity | UNTP MUST accommodate varying levels of technical maturity — from paper-based documents to fully digitalised systems — so that any implementer can proceed without depending on the capability or readiness of upstream or downstream actors. | Human Rendering, resolvability |
| AR.05 | Simplest possible core | UNTP MUST prioritise simplicity by specifying only the minimum that represents common core needs across different jurisdictions and industries, so that implementation costs are minimised and interoperability is maximised. | Architecture |
| AR.06 | Re-use, not re-invent | UNTP MUST re-use existing open and free standards — such as W3C Verifiable Credentials and UN vocabularies — wherever they are fit for purpose, so that interoperability is maximised and existing software investments are reused. | Architecture |
3 — Traceability & Transparency Requirements
UNTP must provide the traceability and transparency data each supply chain actor needs to meet due diligence obligations and customer expectations for verifiable evidence of sustainable practices.
| ID | Name | Requirement | Solution |
|---|---|---|---|
| TT.01 | Data carriers | UNTP MUST define consistent methods for discovering product data from both new and existing data carriers — ID barcodes, 2D matrix codes, QR codes, and RFID tags — so that any party holding only a product batch ID or shipment ID can find ESG data for that product or shipment. | Identity Resolver |
| TT.02 | Item/batch granularity | UNTP MUST provide data at the granularity of individual items or batches in a shipment, so that downstream actors can aggregate material inputs — such as Scope 3 emissions — into their own ESG performance data. | Digital Product Passport |
| TT.03 | End-to-end traceability | Subject to privacy and confidentiality constraints, the UNTP traceability model MUST trace value chains from finished product to raw materials across any number of commercial boundaries (sale of goods), logistics boundaries (consolidation and deconsolidation), and process boundaries (manufacturing transformation of inputs to outputs), so that the provenance and ESG footprint of goods can be verified as the sum of parts. | Traceability Events |
| TT.04 | Sustainability data | UNTP MUST provide a consistent, straightforward way to access and verify all available sustainability metrics — carbon intensity, deforestation, water usage, fair work, etc. — for a given product item or batch, so that product buyers can meet their sustainability and due diligence obligations. | Digital Product Passport, Conformity Credential |
| TT.05 | Provenance data | UNTP MUST provide verifiable provenance information — raw material content and manufacturing origin countries — for a given product item or batch, so that product buyers can meet supply chain resilience and goods origin controls. | Digital Product Passport, Guarantee of Origin |
| TT.06 | Circularity data | UNTP MUST provide a simple mechanism to access circularity data — including recycled content metrics and end-of-life recycling information — so that product buyers can meet recycled content goals and recyclers can optimise their processes. | Digital Product Passport, Circularity Data |
| TT.07 | ESG vocabulary | Given the volume and diversity of ESG standards and regulations, UNTP MUST define a scalable, straightforward mechanism to determine both the precise meaning and the general category of ESG claims, so that downstream actors can map either the specific criteria or the general category of ESG data with confidence. | Vocabulary |
| TT.08 | Rules as code | UNTP MUST define a mechanism to simplify compliance assessment of entities, products, and processes against the fast-growing set of ESG standards and regulations, so that any actor's investment in sustainable ESG practices can be tested against multiple criteria. | ESG Rules |
4 — Trust & Integrity Requirements
UNTP must provide data that is trustworthy and resilient to scrutiny.
| ID | Name | Requirement | Solution |
|---|---|---|---|
| TI.01 | Trust anchors | Trust in the authenticity of sustainability claims can be established through third-party audits, attestation by trusted authorities, or long-standing evidence of sustainable behaviour. UNTP MUST provide a mechanism to link ESG claims to any or all of these trust anchors, so that downstream actors can be confident that claimed ESG performance is genuine. | Trust anchors |
| TI.02 | Identity integrity | UNTP MUST provide a mechanism to verify that ESG claims about products, locations, or entities are made by actors who genuinely own the identifiers or are their authorised delegates, so that downstream actors can be sure parties are genuinely authorised to make such claims. | Identity Anchors |
| TI.03 | Accreditation | Third-party audits and assessments add trust. Where a verifier does not know the auditor or certifier, UNTP MUST provide a mechanism to link third-party certifiers to the accreditation authority under which they operate, so that downstream actors can trust certificates even when they do not know the certifiers. | Conformity |
| TI.04 | Document verification | UNTP MUST define standard, interoperable mechanisms to prevent spoofing or tampering with any documents issued by upstream actors, so that downstream actors can be confident that claimed identity and genuine ESG credentials have not been altered. | Verifiable Credentials |
| TI.05 | Graph verification | ESG performance evidence in supply chains is not concentrated in a single document but distributed throughout the value chain. UNTP MUST define a mechanism to describe and verify evidence available from chains of linked documents, so that downstream actors can ascertain the complete ESG footprint and provenance data for any shipment. | Trust Graphs |
| TI.06 | Product substitution | As the brand value of verifiably sustainable products increases, so does the incentive to attach fake products to genuine sustainability evidence. UNTP MUST define an anti-counterfeiting mechanism so that downstream actors can confirm they have purchased genuine goods. | Anti-counterfeiting |
| TI.07 | Mass balance fraud | Mass balance fraud occurs when a supply chain actor blends sustainable materials with cheaper non-sustainable materials and then claims the manufactured product is 100% sustainable. UNTP MUST define mechanisms to detect mass balance fraud, so that downstream actors can be confident in the integrity of their sustainable supply chain and that the value of sustainable products is maintained. | Chain of Custody |
5 — Security & Confidentiality Requirements
UNTP must protect the security and confidentiality of supply chain data, letting each actor choose their own balance between traceability and transparency.
| ID | Name | Requirement | Solution |
|---|---|---|---|
| SC.01 | Transparency vs confidentiality | UNTP MUST allow every supply chain actor to choose their own balance between transparency and confidentiality, so that each actor can share only what delivers value while protecting information they deem confidential. | Confidentiality |
| SC.02 | Multi-layered security | Product information ranges from public to highly confidential. UNTP MUST provide a range of data protection mechanisms that supply chain actors can apply appropriately to choose the right protection level for specific data sets. | Confidentiality |
| SC.03 | Selective redaction | ESG data and credentials from sellers may contain information buyers do not want to pass on to their customers. UNTP MUST define a selective redaction method that lets any supply chain actor redact information — without affecting cryptographic integrity — from upstream credentials before passing them to downstream customers, so that verifiable ESG data can flow without leaking commercially sensitive data. | Confidentiality |
| SC.04 | Revocation | UNTP MUST provide a mechanism to revoke previously issued conformity certificates when an actor is found non-compliant, so that downstream actors can be confident in the currency of the ESG assessments they receive. | Verifiable Credentials |
| SC.05 | Availability | UNTP MUST define a mechanism to ensure high availability and long-term durability of ESG evidence, so that verifiers can access data even when source systems are down — and so that data for long-use-cycle products such as batteries or building materials remains accessible long after source systems are retired. | Verifiable Credentials |
| SC.06 | Cryptography | UNTP MUST support flexibility in cryptographic methods so that new algorithms can be adopted as they emerge to meet new challenges such as quantum computing. | Verifiable Credentials |
| SC.07 | Key management | UNTP MUST provide mechanisms for discovering public keys, protecting private keys, and rotating key pairs, so that keys remain secure and can be re-chained if compromised. | Verifiable Credentials |
6 — Compatibility & Interoperability Requirements
UNTP must be compatible with existing standards for technology, ESG criteria, and supply chain practices so that implementers can maximise the leverage of existing investments.
| ID | Name | Requirement | Solution |
|---|---|---|---|
| CI.01 | National regulations | UNTP-conformant data SHOULD be straightforward to map to national ESG regulations, so that it can provide upstream B2B ESG evidence to support national B2C product conformance. | Vocabulary, Extensions |
| CI.02 | Entity ESG reporting | UNTP-conformant ESG data on products and shipments MUST be straightforward to map to entity-level ESG reporting obligations, so that transaction-level UNTP data can be easily aggregated to inform annual ESG reporting conforming to standards such as IFRS Sustainability. | Vocabulary |
| CI.03 | ESG standards | UNTP MUST support ESG claims against criteria from any ESG standard and MUST provide a mechanism to map those claims to a common vocabulary, so that implementers can align with standards of their choice and verifiers can interpret claims even when unfamiliar with specific standard criteria. | Vocabulary |
| CI.04 | Credential interoperability | The verifiable credential landscape is fast-moving. UNTP MUST work with multiple technical credential standards — including W3C VCs, IETF JWT, and ISO mDL — and MUST specify a minimal, simple profile of each, so that interoperability between different implementations is maximised. | Verifiable Credentials, Other Profiles TBD |
| CI.05 | Blockchain independence | Whilst some implementers MAY choose blockchain technologies, UNTP MUST NOT require blockchain for conformant implementations, so that implementers who wish to avoid the costs and complexity of blockchain are free to do so. | — |
| CI.06 | Product identifier compatibility | UNTP MUST allow industry to continue using its preferred existing product identifier schemes and MUST NOT favour one scheme over another. | Identity Resolver |
| CI.07 | Business and facility identifier compatibility | UNTP MUST define a mechanism to support existing identity registers, so that implementers can continue to leverage business identifiers such as tax registration numbers, facility identifiers, and location identifiers under UNTP. | Identity Resolver, Extensions |
7 — Implementation Requirements
UNTP must be implementable at the lowest possible cost, give early implementers a market advantage, and allow the impact of implementations to be tracked.
| ID | Name | Requirement | Solution |
|---|---|---|---|
| IM.01 | Business case | Every UNTP implementer needs confidence that implementation benefits outweigh costs. UNTP SHOULD provide business case templates for each stakeholder type so that decision-makers can fast-track their decision to proceed. | Business Case |
| IM.02 | Open source tools | UNTP MUST include an open-source reference implementation that any supply chain actor can embed in their solutions to fast-track implementation. | Tools |
| IM.03 | Conformity testing | UNTP MUST include a conformance test suite and test service so that implementers can self-assess conformance and be confident their implementations will be interoperable. | Test service |
| IM.04 | Implementation support | UNTP MUST provide mechanisms for implementers to obtain community or professional support to minimise implementation risk. | Support |
| IM.05 | Tracking implementations | UNTP MUST provide a mechanism to track implementations so that uptake and impact can be measured and early implementers can publicise their solutions. | Implementations |
| IM.06 | Tracking extensions | UNTP MUST provide a mechanism to track and publish industry and jurisdictional extensions so that new extensions can find and reuse relevant work. | Extensions |
| IM.07 | Tracking outcomes | Uptake is a straightforward measure of success, but UNTP's real purpose is to lift the value of sustainable practices. UNTP MUST develop a set of KPIs to track and assess whether it achieves material impact. | Greenwashing KPIs |
Key changes:
- Requirement statements tightened throughout: Redundant preamble removed from the start of each statement — "The UNTP MUST define a standard protocol that is easy to implement" → "UNTP MUST define a standard protocol that any business software system can implement."
- Active voice in requirement statements: "can be established", "is stored", "are made by actors" recast where the subject was clear.
- Omit needless words: "in a straightforward and consistent way", "in any way", "both…and" constructions tightened throughout.
- Numbering anomaly corrected: TT.07 Rules as Code appeared in the Architectural Requirements section in the source — moved to Traceability & Transparency where it belongs, renumbered as TT.08, and a placeholder AR row removed.
- Column header "Requirement Statement" → "Requirement": Shorter and unambiguous.
- Category introductions: Each rewritten as a single plain sentence rather than a passive description of intent.
- PDF formatting artefacts removed: Broken words, missing spaces, and run-together text from PDF extraction cleaned throughout.