Conformity Vocabulary Catalogue
A conformity claim in a credential records what was assessed and what the assessment found, but it does not carry the definitions it is assessing against. Instead it points at them: a conformity scheme published by whoever owns it, usually a versioned profile within that scheme, and the criteria the assessment covered. Those pointers are URIs, and a claim may name fewer of them than you expect, since a profile is not required.
For those URIs to mean anything to the Reference Implementation, it needs the scheme documents they refer to. This page describes where those documents come from, how they are kept current, and which tenant sees which of them.
The UNTP v0.7 model
Under UNTP v0.7, UNECE does not publish the schemes themselves. The catalogue is to be a register of pointer URIs: a list saying "a conformity scheme lives over there". Each scheme owner publishes their own scheme document at their own stable URI, and that document inlines its profiles, and each profile inlines its criteria.
Two consequences shape everything below. Scheme content is owned and changed by other people, so a copy held here can go stale. And profile and criterion URIs are independently versioned while a scheme URI is not, so a claim naming .../criterion/forced-labour/1.0.0 is naming one exact revision of that criterion.
The Reference Implementation keeps its own local catalogue of scheme documents it has resolved. Every check it performs, and everything its API returns, is answered from that local catalogue rather than from the network.
Where schemes come from
A fresh deployment holds no schemes at all. The core seed does not insert any, so an issuer browsing the catalogue on an untouched install gets an empty list rather than a starter set. Schemes arrive only through one of the sources below.
Three sources can feed the local catalogue. They are at different stages, and the difference matters if you are deciding what to rely on today.
Operator seeding, live
An operator lists scheme documents in the custom seed manifest, either as a URL to fetch or as a file mounted into the container. These land in the system tenant and are visible to every tenant.
The manifest is the source of truth for the schemes it owns. An entry with no matching row is inserted, a changed entry is updated in place, and a scheme whose entry has been removed from the manifest is deleted along with its profiles. Only operator-seeded schemes are ever removed this way, and when a file entry cannot be resolved the removal pass is skipped entirely rather than deleting schemes on the strength of an incomplete manifest. Custom seed covers the manifest format and this behaviour in full.
Seeded schemes also refresh their content from source, not just their membership. At boot every manifest entry is re-ingested; URL entries go through a conditional fetch and file entries are compared by digest, so an unchanged document is detected cheaply and skips parsing and persistence. Between boots, an interval re-fetches the URL-seeded schemes on the nominal cadence set by CVC_REFRESH_INTERVAL_HOURS, spread by a small jitter so instances do not all wake together (see Startup). The periodic refresher handles URL-seeded schemes only; schemes seeded from a mounted file are re-read at boot instead.
Discovery from the UNTP register, not operational
The intent is that the Reference Implementation reads the UNECE register named by CVC_REGISTRY_URL, follows each pointer URI, and ingests the schemes it finds.
This is not running. The resolution and ingest machinery exists, but nothing triggers it and no startup path reads that variable, so setting it has no effect today. UNTP's current published artefact is a scheme owners registration page rather than the machine-readable register this would read, which is promised before the first stable release. Wiring the trigger is tracked in #690, and the wider discovery capability in #543.
Tenant-level import, not built
The intent is that a tenant supplies a scheme URI and gets that scheme resolved into its own lane, without an operator changing the deployment's manifest. This is useful when a scheme matters to one tenant and not to the platform.
No endpoint exists for this yet, and nothing in the product writes a tenant-owned scheme row. The design is recorded in ADR-033.
Keeping the catalogue current
Because scheme owners can change a document after it is published, a copy here is only as good as its last successful fetch. A successful re-ingest replaces the stored scheme, its profiles, and its criteria with what the document now says. Within a tenant's lane a canonical URI appears once, so a changed document updates what is already there rather than accumulating copies of the same URI beside it.
A failed fetch leaves the previous content in place rather than emptying the catalogue. That is the safe behaviour, but it means a stale entry and a current one look identical through the browse API, which returns only the catalogue content and no fetch metadata. An operator checking whether refresh is actually working should look at the startup and interval logs, where each pass records what it fetched and what failed.
What is implemented today is the seeded-scheme refresh described above. Refresh driven by register discovery waits on the discovery trigger, and an endpoint to force a refresh on demand rather than waiting for the interval is tracked in #666.
What each tenant sees
A tenant browsing the catalogue sees the system catalogue plus anything in its own lane. Where the same canonical URI exists in both, the system-tenant entry wins, so a tenant cannot shadow a platform-provisioned scheme with a private copy of the same URI. The same precedence applies when a credential is validated during issuance, so what a tenant browses and what its claims are checked against agree.
Since tenant import is not built, every tenant sees the same system catalogue today. How a tenant's own entry should behave once its URI is also registered upstream is tracked in #664.
Using the catalogue
Issuers browse the catalogue through the Conformity Vocabulary Catalogue API, drilling from scheme to profile to criteria and taking the canonical URIs to put in a claim.
Conformity claims in a UNTP v0.7.0 Digital Conformity Credential are checked against the catalogue as it is issued. Earlier DCC versions are still supported for issuance and are seeded by default, but they carry no claim extraction, so a v0.6.0 or v0.6.1 credential is issued without this check and without CVC warnings.
The check is advisory and never blocks a credential: see CVC compliance on the Credentials API page for the warnings it produces, and Conformity Handling for how conformity data is modelled across the credential types that carry it.