Please note that this specification is suitable for pre-production pilot implementations.
UNTP Community Activation Register — Governance
Purpose
The register answers three questions.
For someone receiving an unfamiliar credential: what community stands behind this extension, and has UNECE tested that it is a conformant UNTP extension?
For a community considering activation: has somebody already done my sector, and what did they choose to build on?
For a software vendor or scheme owner: which communities exist, and which of them use what I provide?
The registered thing is the community, not the specification. An extension needs an owner that stands behind it, and the reason one exists is almost always a sector need, so each extension sits beneath its owning community with a stable identifier of its own. A community that adopts another community's extension links to it rather than registering it again.
Two kinds of authority, exercised at different times
Admission is a judgement about the community, made once. The UN secretariat admits a CAP to the register, supported by the existing Team of Specialists, on the basis of a published self-declaration against the criteria in the registration guide. Removal follows the same route and is reactive on complaint rather than by periodic audit.
Everything after that is observation. The registrar agent crawls what each community publishes and records what it finds, with a date attached. It originates nothing except the extension conformance verdict.
That split matters because it determines what a reader can rely on. An entry says the community met the criteria on the date it was admitted, and that these are the things it declared it builds on as at the last crawl. It does not say those things are endorsed by UNECE.
What the register holds, and what it does not
Pointers, hashes and dated observations, never definitions. Every technical artefact belongs to whoever published it. The register says where it is, that it has not changed since it was tested, and what was found when it was last checked.
A consequence worth stating: if a community ceases and its hosting lapses, a hash proves nothing about a document nobody can fetch. That is what the wind-down commitment in the admission criteria is for, and it is the register's weakest point.
Roles
| Role | Identity | Responsibilities |
|---|---|---|
| Registrar | UNECE | Owns the register and its schema; admits and removes communities through the secretariat; operates the registrar agent; mediates disputes. |
| Registrar Agent | did:webvh:untp.unece.org | Crawls each community's published profile, records what it finds as dated observations, and runs the extension conformance suite. |
| Community (CAP) | Community DID | Publishes a profile, owns at most one extension, declares what it builds on, and asserts which software conforms to its extension. |
| Sector or regional forum | Forum site | Lists communities. Originates nothing. See below. |
| UNTP Core Maintainer | UN/CEFACT | Maintains the core specification that extensions extend, and coordinates breaking changes. |
Who may assert what
| Statement | Asserted by |
|---|---|
| This community met the admission criteria | The secretariat, on the community's declaration |
| This extension is a conformant UNTP extension | UNECE |
| Software passes core UNTP tests | UNECE, recorded in the software implementers register |
| Software conforms to extension X | The community owning X, which did the testing |
| This community uses scheme or system Y | The community |
A community asserting conformance to its own extension is doing the testing UNECE cannot do, because UNECE does not know the extension's requirements. A community asserting its software passes core tests would be self-certification, which is why that one stays with UNECE. A community's conformance credential cites the software's core registration, so the requirement to pass core tests first is visible in the data rather than enforced by procedure.
What the agent verifies
Two separate things, on different cadences.
The extension conformance suite, run when an extension version is submitted and on request thereafter. These are the same checks described on the Extension Vocabularies page, because an extension conforms by the same rules whoever is checking.
| Check | What it means |
|---|---|
| Samples validate against the extension schema | The extension's own examples satisfy its own schema. |
| Samples validate against the core schema | An extension credential is still a UNTP credential. |
| Safe-mode expansion loses nothing | No property is silently dropped when the credential becomes a graph. |
| No protected term redefined | The extension has not changed the meaning of a core term. |
| Every minted IRI resolves | Terms the extension invents can be looked up. |
The profile crawl, run periodically. The agent fetches the community's published profile, records the identifier schemes, conformity schemes and software it declares, and timestamps each. Staleness is derived from lastCrawled and crawlStatus; it is deliberately not a lifecycle status, because a site that is down for a fortnight is not a community that has folded.
Relationship to forums and CAP pages
A forum is a meeting room, not an owner. Sector forums such as agrifood.untp.unece.org and regional forums aligned with the UN regional economic commissions list the communities convening there. A community may appear on several forums, or on none, and some organise entirely outside the forum process.
Forums validate nothing and originate nothing. They list communities that are already in this register, and display the conformance verdict with its source attached rather than minting one of their own. The failure mode to design against is a community appearing on a UN-hosted domain and the listing being read as an endorsement of its specification.
Because a community's sector and geographic scope are already in its register entry, most of a forum's content is derived: a sector forum is a query on one field and a regional forum a query on the other. Two kinds of listing follow, and they are worth keeping apart. Discoverable here is derived from declared scope, and a global community matches every regional forum, which is noise rather than membership. Convenes here is an explicit statement by the community about where it actually participates.
A CAP page on a forum site is part editorial and part generated. Narrative, images, the named human contact and governance prose belong to the community and are written locally. The four technical tables — credential extensions, identifier schemes, conformity schemes and software systems — are generated from this register at build time, so a change here reaches every forum on its next deploy and nothing is maintained twice.
No durable identifier is forum-scoped. A community joining or leaving a forum changes that forum's list and nothing else: no identifier rewritten, no extension re-registered, no admission decision re-run.
Lifecycle
A community that folds becomes dormant rather than being deleted, because credentials issued under its extension stay in circulation and a verifier still needs to resolve what the terms meant. withdrawn is for a specification retired deliberately. The two can differ from the extension's own state: an inactive community can own a perfectly valid extension.
Trust boundaries and failure modes
| Threat | Mitigation |
|---|---|
| A community declares criteria it does not meet. | Admission is on a published self-declaration, and removal is reactive on complaint. The declaration URL is recorded, so what was claimed is auditable. |
| A community silently modifies its extension after conformance testing. | The entry records the hash of each artefact as tested. A mismatch is detectable by anyone, not only the registrar. |
| Hosting goes offline. | The crawl records the failure. A hash proves integrity but recovers nothing, so the wind-down commitment is the only real protection. |
| Declared uptake is inflated. | Declared and observed uptake are separate numbers. A community can list ten systems it uses; observed uptake comes from the registrar detecting extensions in credentials in the wild. Quote the observed figure for adoption claims. |
| Two extensions define the same credential type name. | Disambiguation is by context IRI, not by type name. The register permits the collision; verifiers resolve types through the credential's @context. |
| A forum listing is read as endorsement. | Forums display verdicts from this register with their source attached and mint none of their own. |
| Registrar agent compromise. | Each observation is signed. UNECE can re-run validation and amend or retract specific observations. Retractions are recorded, not silently deleted. |
Disputes
A community files a dispute with UNECE. UNECE re-runs validation independently; if upheld, the observation is amended, the original retained and marked retracted, and the new observation links back to it. Disputes about the interpretation of a rule rather than the data follow the change-control process below.
Relationship to other registers
- Software Implementers Register — core conformance for a software product is recorded there. A community's assertion that software conforms to its extension cites that entry.
- Identifier Scheme Register — identifier schemes a community builds on, where they are registered. Many are not: a national business register belongs on GRID rather than here, and plenty are simply named until somebody registers them.
- Conformity Vocabulary Catalogue — conformity schemes a community builds on.
Links into those registers carry both an adoption status and a registration state, because they are different facts. A scheme can be in production use by a community and still have no UNTP entry.
Change control
Changes to this document, the register schema, or the conformance rules are managed under the UN/CEFACT Open Development Process and announced at least 30 days before taking effect. Changes that would invalidate currently-conformant extensions get a longer window, typically 90 days, and a migration guide.
Feedback should be filed as an issue on the UNTP specification repository or sent to UNECE through the usual channels.