info

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

Community Activation Program

Introduction

A Community Activation Program (CAP) is a framework for existing communities to solve trade interoperability together. A CAP is typically run by a membership organisation (a national industry body, a sector association, a responsible-production scheme) that already has members with reasons to coordinate: producers, buyers, certifiers, and the operators of the identifier and software systems its members already use. The CAP does not create this community. A CAPs output is a community adopting UNTP and realising the benefits of lower compliance costs, improved market access, and reduced implementation costs.

UNTP is a base protocol; every community needs its own extension to model the products, claims, conformity structures, and traceability events specific to it. A CAP is how a community produces that extension and brings its members from the specification to working systems.

CAPs sit at the specific-industry level, where a convening organisation can act for its members. Broader groupings (multiple regional communities covering the same global industry, or multiple adjacent industries) coordinate at the sectoral forum level, not inside any one CAP. See Sectoral Collaboration Fora.

A CAP produces three things:

• A UNTP extension - the community-specific specification of proofs, vocabularies, and rules needed to make the community's claims verifiable, consistent with UNTP and interoperable with adjacent communities by design.
• Coordinated adoption across the community's members - rather than each member implementing independently, a CAP coordinates at community level. Members share costs by reusing the UNTP registered technical roots (the CAP register of community activation programs and the extensions they own, the CVC register of conformity schemes, the IDR register of identifier schemes, and the SWI register of software vendors), and collaborate with adjacent CAPs through sectoral fora. Each register is continuously maintained by the UNTP registrar agent, so a community choosing conformant entries inherits continuous cryptographically-verified conformity assurance.
• UNTP capability within the community - practitioners from the community's members, software vendors, conformity bodies and scheme operators develop a shared working practice around issuing, consuming, and maintaining the community's UNTP credentials. This capability is what sustains the extension once it is live.

CAPs are governed by the communities that run them. In order to be recognised and registered as a UNTP CAP, the outputs of the CAP MUST be released under an open licence appropriate to each artefact type: an OSI-approved open-source licence for software (reference implementations, test suites, tooling), and CC BY 4.0 or equivalent for schema, vocabulary, and documentation.

Launching a CAP typically requires:

• An adoption catalyst such as new regulatory requirements (ESPR, CBAM), a national or sectoral traceability strategy, or demand from buyer markets. The catalyst gives stakeholders focus and the sense of urgency to coordinate.
• Engaged buyers who perceive value in supplier data, whether for compliance assurance, enhanced quality, risk mitigation, or market signal, so that demand pulls implementation into the community.
• Committed suppliers willing and able to share data with those buyers, usually because the work delivers direct benefits such as reduced reporting burden, increased market access, or reputational gains.
• A funding mechanism. The beneficiaries of a CAP (its buyers, suppliers, and convening organisation) typically co-fund it, sometimes alongside government or development-bank support. A CAP whose beneficiaries do not co-fund is asking a third party to pay for outcomes the beneficiaries will capture, which is a fragile model worth examining before accepting.
• Engaged buyers and committed suppliers describe two functions, not two separate groups. Most members of a community do both: a mill buys fibre and supplies yarn. A CAP should expect to inform each member about the buying function and the supplying function.

Trade facilitation bodies and corridor operators often help an existing industry body stand up a CAP, especially where this brings lower-maturity actors (small exporters, producers in developing economies, organisations without dedicated compliance infrastructure) into UNTP participation collectively. For context, see Low Digital Maturity Organisations. A lower-maturity member can start with the buying function alone, receiving and verifying credentials as a credential consumer, and add issuance later, for example through delegated issuance once the trust chain mechanics for it are in the specification.

Stakeholders and roles

A CAP is a collaboration among seven kinds of stakeholder, each contributing distinct value to the community:

#	Stakeholder	Role
1	Convening organisation	Leads the CAP. Coordinates implementation across its membership, selects registered technical components, represents the community in the relevant sectoral forum, and holds accountability for the extension as it evolves.
2	Suppliers	Produce the physical or intangible goods the community makes verifiable claims about, and issue the credentials that carry those claims (passports, facility records, traceability events).
3	Buyers	Verify and act on supplier credentials - in procurement, compliance, market-access, and risk decisions. Buyer demand is what pulls verifiable claims into use.
4	Conformity schemes	Publish the criteria, scoring frameworks, and attestation structures against which supplier claims are assessed. Catalogued in the CVC register, where each entry is continuously verified by the registrar agent.
5	Conformity assessment bodies (CABs)	Independently assess suppliers against scheme criteria and issue the Conformity Credentials (DCCs) that record the assessment outcomes.
6	Identifier schemes	Operate the identifier services credentials reference (product, facility, member, asset identifiers), publish IDR-register entries, and optionally issue Digital Identity Anchor credentials to registered entities.
7	Software systems	Provide the operational platforms that issue, hold, and verify credentials in production. SWI-register entries carry observed conformance results, so the community can rely on listings without separate vendor due diligence.

How these roles typically appear in a CAP

• Convening organisation. Already-existing industry associations, national sector bodies, standards organisations, or responsible-production schemes with authority to coordinate their membership. The convening organisation is what makes a CAP viable; a CAP without one has no accountability structure. If the convening organisation cannot articulate its ownership stance to its buyers, suppliers, and conformity schemes, the CAP does not yet have community backing, and that is Inception work to complete before proceeding.
• Suppliers and buyers. The producers and purchasers in the community: mills, farms, factories, refineries, processors, retailers, OEMs, downstream manufacturers, government procurement, importers and exporters. Most perform both functions: a processor buys from farms and supplies manufacturers. See Buying and Supplying. They are the primary beneficiaries of a CAP (the parties who capture value from verifiable claims), which makes them natural co-funders alongside the convening organisation.
• Conformity schemes and CABs. Conformity schemes are typically national or international certification programmes, standards bodies, or sector-owned frameworks that publish the criteria suppliers are assessed against. CABs are the independent parties (certification bodies, testing laboratories, inspection bodies) accredited to perform those assessments. In practice the scheme owner and the CAB are often, but not always, the same entity: some schemes both set criteria and operate their own assessment service, while others separate scheme ownership from assessment and delegate assessments to accredited third parties. UNTP keeps the two logically distinct in the data model (the criterion owner and the credential issuer are addressed separately), so a CAP should know which pattern applies in its community. Both sit inside the community's existing conformity ecosystem (accreditation bodies, standards organisations, self-assessment mechanisms).
• Identifier schemes. Pre-existing infrastructure to activate rather than build. Every community already has identifier services: barcodes for products, industry member registers, national business registers. The CAP's job during Discovery is to identify which schemes cover its needs and whether their operators will publish IDR entries (and, where relevant, issue DIAs). Where a critical identifier scheme lacks a UNTP register entry, activating it is a Discovery deliverable.
• Software systems. The platforms the community's members already run (ERPs, MES, PLM, industry-specific platforms) extended by their vendors to produce and consume the community's verifiable proofs. The CAP does not build software systems; it works with what the community already has.

Role confusions to watch

Three patterns come up often enough to flag:

• External funders vs the community. Where a government body, philanthropic funder, or industry consortium supports a CAP convened by a membership organisation, it can look like the funder owns the CAP. It does not. Ownership stays with the convening organisation and its members. Check that the convening organisation has internally agreed its ownership stance with its buyers, suppliers, and conformity schemes before treating a funder as a proxy for community backing.
• Buyers and suppliers vs the community. Buyers and suppliers are members of the community. Framings that treat them as external participants hide the beneficiary-plus-co-funder logic and make sustainable CAP funding harder to secure.
• Software system providers vs facilitators. Facilitators who orchestrate a CAP are not themselves software systems in the stakeholder-list sense. The community's operational software systems are supplied by others - any facilitator who also wishes to offer production software to the community is taking on an additional role, distinct from facilitation.

The five phases

A CAP progresses through five phases, each answering a specific question and producing specific outputs. Phase exits are decision gates: at each boundary the community decides to continue, revise, or stop. An extension that reaches Discovery or further has public-good value even if the CAP itself pauses - the schema remains registered and reusable.

Phase	Question it answers	Primary outputs
Inception	Why should this CAP exist?	Business case for Discovery; coalition of committed participants; initial reference implementation with sample credentials
Discovery	What specifically will the CAP build?	Current-practice map; UNTP register-search; extension schema shape; refined reference implementation; Tier-3 coverage test suite; substantive Alpha–Live business case; implementation plan
Alpha	Does the extension work in controlled conditions?	Named implementers running the extension in their own software systems; Tier-3 deep-validation results
Beta	Does it work at production scale across independent implementations?	Multiple independent software systems running the extension; Tier-3 interoperability test results; release-candidate extension specification
Live	Is the community sustaining adoption?	Growing adoption across community members; ongoing community governance; extension maintenance workflow; Tier-3 living regression test suite

Across all phases, the CAP maintains a stakeholder register - the current list of committed participants in each UNTP role - updated at each phase transition so the convening organisation can see what is committed heading into the next phase.

Inception

Inception answers why a CAP should exist, from the beneficiaries' perspective. In Inception the convening organisation and candidate members:

• Confirm the adoption catalyst and gather evidence that it is real (regulation, market pull, strategy).
• Recruit a coalition of buyers, suppliers, and conformity schemes willing to participate in Discovery.
• Build an initial reference implementation that publishes the community's supply-chain map at role-type resolution, with sample credentials, so stakeholders can see concretely what the CAP is being asked to produce.
• Produce a business case covering (a) the value each major beneficiary group captures from the CAP, (b) a complete Discovery ask with scope, cost, and funding path, and (c) an articulated Alpha–Live hypothesis for Discovery to pressure-test.
• Register the extension with UNTP, where the community is ready.

Exit when: the convening organisation can show its committed participants, the business case for Discovery is agreed with those participants, and a funding path for Discovery is secured.

Discovery

Discovery answers what specifically the CAP will build. In Discovery the committed participants:

• Map the community's current practice in depth - existing actors, certifications, attestations, IT systems, data flows, and where each member performs the buying and supplying functions (procurement, supplier onboarding, due diligence, sales, shipping, certification). These are the points where UNTP changes day-to-day work and where staff need to be informed.
• Search the UNTP registers (CAP, CVC, IDR, SWI) for reusable components and produce a reuse-vs-build list that scopes Alpha.
• For each sector-critical conformity scheme, identify whether its CVC content is published (reuse) or needs authoring by the scheme owner (build).
• For each sector-critical identifier scheme, identify whether its IDR entry is published (reuse) or needs activating by the scheme operator (build).
• Agree the shape of the extension schema - key extension points identified, form stable enough to prototype against.
• Refine the Inception reference implementation against the settled schema shape, with sample credentials updated to reflect current-practice mapping.
• Produce a Tier-3 coverage test suite validating that the extension models identified use cases correctly.
• Pressure-test the Inception Alpha–Live hypothesis against the evidence Discovery has produced, and turn it into the substantive Alpha–Live business case.
• Agree the implementation plan with the convening organisation and committed participants.

Exit when: the implementation plan is agreed, the substantive Alpha–Live business case is delivered, extension schema shape is settled, reference implementation and Tier-3 coverage test suite are shipped, CVC and IDR activation paths are agreed for sector-critical schemes, and Alpha funding is confirmed.

Alpha

Alpha answers whether the extension works in controlled conditions. Named alpha implementers deploy the extension in their own software systems, iterating against the reference implementation and the Tier-3 test suite. The suite evolves from coverage (does the extension model the use case?) to deep validation (does it validate correctly against real implementer data?).

Exit when: named Alpha implementers are running the extension and passing Tier-3 deep validation, iteration cycles are closed, the extension specification is stable enough for scaled pilot, Beta funding is confirmed, and the convening organisation has approved the extension specification via community governance.

Beta

Beta answers whether the extension works at production scale across independent implementations. Multiple software systems deploy production-shape, exercising interoperability against each other. Real buyer and supplier pairs from the community make the natural test cases, with the supplier's system issuing and the buyer's system verifying. The Tier-3 suite expands to interoperability tests across those independent systems. A release-candidate specification is contributed to the convening organisation.

Exit when: multiple community software systems are issuing and verifying real sector data using the extension, Tier-3 interoperability is demonstrated across independent implementations, the release-candidate specification is accepted by the community, and the Live operating model (hosting, support, maintenance ownership, funding basis) is agreed.

Live

Live is not a phase to exit - it is the ongoing operation of the extension and its community. The convening organisation operates community governance; the Tier-3 suite becomes a living regression suite that catches drift as the extension evolves; adoption metrics are reported on a stable cadence per the Impact Assessment Framework; and the extension is maintained in step with UNTP evolution, with the community's trade ecosystem, and with sector practice as it matures.

Steady state when: community governance is operating on a stable cadence, buyers and suppliers are adopting at scale through community software systems, extension maintenance is funded and resourced, and Impact Assessment Framework reporting is in place.

Who is most active in each phase

The roles doing the heaviest work change as the CAP matures. The convening organisation is active throughout; the other stakeholders carry different weight in each phase.

Phase	Most active roles
Inception	Convening organisation; candidate suppliers, buyers, conformity schemes
Discovery	Convening organisation; committed suppliers, buyers, conformity schemes; CVC scheme owners and IDR scheme operators
Alpha	Named alpha implementers (suppliers, buyers, CABs); software system providers; identifier scheme operators
Beta	Multiple software system providers; CABs operating at production shape; convening organisation preparing the release
Live	Full community - buyers and suppliers at scale, scheme operators, software providers, convening-organisation governance

The flywheel

A CAP creates value through two mutually reinforcing cycles - one inside the community it serves, one across neighbouring CAPs. Both strengthen as adoption grows, which is what makes a CAP's value accrue over time rather than up front.

Within a CAP

Inside a community, each stakeholder's participation strengthens the case for every other stakeholder to participate.

• Suppliers issuing credentials make it worth buyers' investment to verify them.
• Buyers verifying credentials make it worth suppliers' effort to issue them.
• Conformity schemes with digitally-referenceable criteria make it practical for CABs to issue machine-verifiable DCCs against them.
• CABs issuing DCCs give schemes a reason to maintain their CVC entries.
• Identifier scheme operators publishing IDR entries and DIAs make community credentials resolvable without point-to-point integration.
• Software system providers delivering conformant platforms make all of the above operationally feasible.

Each new participant adds value for existing participants, and the pool of candidates for whom joining is now worthwhile grows with it. This is the mechanism that turns Inception's coalition of committed participants into Live's self-sustaining community.

For the convening organisation leading the CAP, this cycle produces four concrete returns:

• Reduced member costs - members share implementation costs and reuse registered software, identifier services, and conformity schemes rather than sourcing them independently.
• Interoperable implementations - choosing from registered components and collaborating through the sectoral forum ensures member implementations work with each other and with adjacent industries.
• Increased membership value - the CAP gives the convening organisation a new reason for members to join, and a durable reason for them to stay engaged.
• Accelerated adoption - coordinated community action attracts funding from governments and development banks, and builds momentum as early successes demonstrate value to the next wave of members.

Across CAPs

Because every CAP builds on the same base UNTP protocol, extensions produced by neighbouring CAPs remain interoperable by design. As adjacent CAPs come online, the value of any single CAP grows:

• A producer active across industries (a farmer producing both red meat and grain, a mill handling both wool and cotton, a smelter producing copper and cobalt) can reuse proofs about shared operations, land management, and inputs across the CAPs they participate in rather than re-collecting and re-attesting the same facts twice.
• A buyer sourcing from multiple industries verifies proofs the same way regardless of industry - one verification capability, not one per industry.
• An accreditation body or identifier scheme active across industries reuses its UNTP identity across CAPs; each new CAP referencing them raises the value of every earlier CAP that already does.

Cross-CAP coordination has real cost, and that cost lives in the sectoral collaboration forum, not in bilateral conversation between every pair of CAPs. The forum is what lets the external cycle turn with predictable overhead rather than one bilateral negotiation per pair of CAPs.

Running a CAP in an existing community

A CAP does not create a community. The convening organisation has members; those members already have relationships with their buyers, their conformity schemes, their identifier scheme operators, and the software vendors they already run. A CAP is how that existing community turns its attention to UNTP trade interoperability for its members, and keeps that attention focused long enough to produce and maintain an extension.

What Inception activates

Inception is where the existing community decides to invest in UNTP work together. The practical activity:

1. Confirming the catalyst. The convening organisation and its members validate that the adoption catalyst (regulation, market pull, strategy) is real and warrants coordinated attention. This can be a short exercise where the catalyst is uncontested, or a longer one where members disagree on urgency.
2. Securing commitments to the UNTP work. Buyers, suppliers, and conformity schemes who already work with the convening organisation name what they will contribute to Discovery. The underlying relationships already exist; what is new is the specific commitment to the UNTP work.
3. Setting up CAP-specific governance. The convening organisation establishes a governance mechanism for the UNTP work, typically a working group or standing committee drawn from committed members. This is incremental to its ordinary member governance, not a replacement for it.
4. Building UNTP capability within the community. The staff and contractors engaging the UNTP work develop a shared practice around issuing, consuming, and verifying the community's credentials. Capability built here carries forward across phases and across adjacent CAPs if the practitioners move on.

By Inception exit, the convening organisation can show a stakeholder register for Discovery with committed participants named, and a funded Discovery ask.

What sustains CAP activity

The community persists because it always has. What sustains CAP activity within that community:

• Governance. The convening organisation runs its CAP-specific governance (schema versioning, interoperability resolution, admission of new implementers) alongside its ordinary member governance.
• Extension maintenance. The extension evolves with UNTP, with the community's trade environment, and with maturing member practice. Without maintenance it drifts out of step and adoption erodes.
• Reference implementation. The reference implementation produced during Discovery persists as the community's shared anchor. New implementers pattern their platforms against it. It is not a trade platform; commercial issuance and verification runs on the community's software systems.
• Sectoral forum participation. Where the community coordinates with adjacent CAPs. Without active forum participation, the across-CAP flywheel stops turning even if the community's own cycle is healthy.
• Extension registered in UNTP. The extension schema is a public good whether or not the community continues active development. Carried by the CAP's entry in the CAP register, it is discoverable and reusable.
• Practitioner continuity. Practitioners who delivered the CAP continue to support the extension as it evolves, and the generalisable patterns they built travel with them across adjacent CAPs.

When CAP activity stalls

The signal is adoption plateauing. A CAP can be technically operating (governance meets, reference implementation maintained) while adoption flattens: community software systems stop attracting new users, buyer and supplier use stops scaling. The extension survives, since schemas are public goods, but the flywheel stops. Adoption metrics are the leading indicators; drift tends to appear there first.

Impact Assessment Framework at CAP level

UNTP defines an Impact Assessment Framework (IAF) that traces implementation from investment through to measured outcomes. The methodology, metrics, and reporting schema are on the UNTP Impact Assessment Framework page.

For a CAP, the IAF matters at the community-aggregation level. Implementers registered within the community submit periodic volumetric reports through the UNTP implementation-registration mechanism; the convening organisation aggregates those reports to produce community-level dashboards that:

• Track adoption of the extension over time across the community's members.
• Demonstrate realised value to prospective members and to funders.
• Feed the global UNTP picture by rolling up to UN/CEFACT-level dashboards.

The IAF loop is the convening organisation's empirical answer to "did this actually work?" Without it, the adoption-plateau signal has no basis and sustainment decisions are made in the dark.

Success metrics

A CAP succeeds when it produces adoption pull in the community: not just infrastructure being adopted, but members actually using it. Metrics belong on two sides, plumbing and use. Plumbing without use is a technical success but a business failure.

Plumbing (infrastructure adoption):

• Software system adoption. The platforms the community's members run in production implementing the extension.
• Conformity scheme adoption. Schemes publishing their CVC content and CABs issuing DCCs that reference CAP-produced credentials.
• Identifier scheme adoption. Scheme operators publishing IDR entries and, where relevant, issuing DIAs to registered entities for CAP use.

Beneficiary use (what the plumbing enables):

• Supplier issuance. The community's suppliers issuing proofs on their operations, products, and claims.
• Buyer verification. The community's buyers verifying CAP-produced proofs and using them in procurement, compliance, or market-access decisions.

Phase-specific leading indicators:

• Inception - business case delivered; Discovery funding path secured; extension registered with UNTP; stakeholder register for Discovery with committed participants named.
• Discovery - implementation plan agreed; substantive Alpha–Live business case delivered; Alpha funding path confirmed; refined reference implementation and Tier-3 coverage test suite shipped.
• Alpha - count of named alpha implementers running the extension; Tier-3 deep-validation results documented.
• Beta - count of production-shape implementers; Tier-3 interoperability demonstrated across independent software systems.
• Live - adoption metrics growing on both sides (plumbing and use); IAF reporting established on a stable cadence.

End-adoption at scale across the community's membership is a downstream effect of these leading metrics and grows on multi-year timeframes. A CAP's early-phase success is measured by its leading indicators, not by universal adoption.

What a CAP is NOT

A few patterns are worth naming explicitly, because the shape of a CAP is easy to mistake for things it isn't.

• Not a live production trade platform. The reference implementation is a definition anchor and a demonstration artefact. It gives the community a shared reference against which members' platforms can be patterned and tested, across all phases. It is not where real commercial issuance and verification happens; that runs on the community's own software systems. If a convening organisation chooses to offer its members a hosted platform to accelerate adoption, it is taking on an additional role as a software system provider, distinct from its CAP convening role.
• Not development of the base UNTP protocol. The UNTP standard itself is maintained by UN/CEFACT. What a CAP develops is the community's own extension built on UNTP, coordinated with adjacent CAPs through the sectoral forum.
• Not a replacement for the community's existing conformity ecosystem. A CAP digitises what the community's accreditation bodies, standards organisations, CABs, and self-assessment mechanisms already do. It does not replace them.
• Not a vendor-owned framework. CAPs are UN/CEFACT open-development communities. The extension and its community governance belong to the convening organisation and the community's members, not to any facilitator, consultant, or software vendor engaged along the way.
• Not a one-off project. The extension, the community's UNTP capability, and the governance that maintains them are intended to persist. Projects that treat the CAP as a time-bounded delivery and dissolve the community at the end leave the extension exposed to drift and the community without a maintenance mechanism.

Interlocks and failure modes

A CAP sits inside a wider system: UNTP, other CAPs, the community's existing conformity ecosystem, and the regulatory environment its members already work within. The connections to that system and the ways a CAP can fail are worth understanding before starting rather than mid-flight.

The extension interlock

The extension is a CAP's most durable output. The convening organisation and the community's members own it; UN/CEFACT admits the CAP to the CAP register once it is ready, usually late Inception or during Discovery, with the extension carried beneath it. Extension versions evolve through Alpha (schema settles), Beta (release candidate), and Live (maintained in registry). Where multiple CAPs cover the same global industry across regions, schema evolution is coordinated through the sectoral forum so that regional variants do not drift into incompatible forks. An extension can be published even if the CAP itself pauses: an unadopted extension is still a public good. Admission to the register and ongoing observation of what each community publishes are described under Register Governance.

The cross-CAP interlock

Cross-CAP coordination lives in the sectoral collaboration forum. Convening organisations from adjacent CAPs meet in the forum to harmonise schema, terminology, and register-search. Every CAP should identify which forum it participates in and at what cadence; without active forum participation, the across-CAP flywheel described earlier does not turn.

A forum validates nothing and originates nothing. It lists communities that are already in the CAP register and surfaces the registrar agent's conformance verdict with its source attached. A community may convene at several forums or at none, and nothing in a community's durable identity is forum-scoped — joining or leaving a forum changes a listing and nothing else.

Each community that convenes at a forum typically has a CAP page on that forum site. Those pages are part editorial and part generated: narrative, images, named contacts and governance prose belong to the community and are written locally, while the technical tables of extensions, identifier schemes, conformity schemes and software systems are generated from the CAP register at build time. A change made in the register reaches every forum the community convenes at on its next deploy, and nothing is maintained twice.

Shared OSS tooling that CAPs use to build reference implementations evolves on the basis of cross-CAP learnings; improvements flow back to the OSS repositories, not into any single CAP's private codebase. Practitioner capability travels similarly, carrying generalisable patterns across adjacent CAPs. These shared assets are what make cross-CAP learning routine rather than incidental.

Durable storage for longer-lived products

A credential issued for a product that outlasts its issuer loses value when the issuer ceases to operate. The issuer's domain lapses, its signing keys become unresolvable, and the credential can no longer be verified even though the product remains in use, resale, or recycling. For products with long service lives, continuity of the credential matters as much as its accuracy at issuance.

A CAP serving such products should set a minimum expectation: credentials for longer-lived products are lodged at issuance with a durable third-party custodian (an industry association, trade body, or accreditation body whose continuity does not depend on any single member or issuer).

Lodging serves its purpose only if three conditions hold:

• Independence. The custodian is separate from the issuer. A copy held by the issuer fails when the issuer fails.
• Verifiability. The custodian holds the signed credential unaltered, and the issuer's public key material remains resolvable for as long as the credential must be verifiable.
• Access. Any access conditions the issuer set, including restrictions on confidential or tiered data, continue to apply after transfer to the custodian.

The community decides what counts as longer-lived for its context, taking into account typical service life and any regulatory retention requirements (such as EU ESPR provisions on continued availability of passport data). The CAP sets its threshold at or above any applicable regulatory minimum, records who acts as custodian and what the custodian undertakes if an issuer ceases to operate, and plans how a successor custodian takes over if the custodian itself ceases. Custodianship is not yet a UNTP register and is not verified by the registrar agent; each community confirms its custodian meets the conditions above.

Phase-gate decisions

Phase exits are decision gates. The community can continue to the next phase, revise and retry the current phase, or wind down. An early-phase decision not to proceed (particularly at Inception → Discovery) is a healthy outcome rather than a failure - the convening organisation and its members have learned enough to decide this is not the right time, and the artefacts produced (including any registered extension) remain public goods.

Where a CAP winds down, it typically does so by parking (preserve artefacts, close out the community's UNTP activity), by deferring until funding or a renewed catalyst re-emerges, or by handing the extension and governance off to another party. An extension carried on the CAP register is a public good whichever path is taken.

The signal that it is time for one of these decisions is that phase exit criteria cannot be met across repeated attempts. The convening organisation and any external funders should talk about it honestly rather than extend indefinitely.

IP defaults

Clear IP allocation agreed up front avoids disputes later. The defaults for a CAP:

• Protocol elements (UNTP, UNVTD, GRID, UN Locodes, UN Core Vocab) are maintained by UN/CEFACT and are not changed by any CAP.
• The community's UNTP extension is a public good. Stewardship vests with the convening organisation on behalf of the community's members. The extension (schema and vocabulary) is carried on the CAP's entry in the CAP register, released under CC BY 4.0 or equivalent, and remains discoverable and reusable regardless of the CAP's subsequent activity.
• CAP work product (reference implementation, test suite, deployment, business case, and other artefacts produced through the CAP) belongs to the community collaborating on each CAP, with allocation reflecting the financial and in-kind commitment of contributing parties. Allocation should be settled explicitly at CAP setup rather than left implicit.
• Shared OSS tooling that supports UNTP implementation across CAPs (reference tools, test harnesses, utilities) is released under OSI-approved licences and belongs to UN/CEFACT and its contributors. CAPs may use and contribute improvements to these tools, but do not take ownership of them.
• Facilitator and vendor IP that a party brings to a CAP (delivery methodology, proprietary platforms, pre-existing software) remains with that party. What a facilitator or vendor contributes to the community's extension or reference implementation is a separate contribution and follows the extension's licence.