Registry capabilities are hard to discover
A ministry of health maintains a facility registry of 1,200 hospitals, clinics, and rural health posts in a vendor portal. A licensing authority wants to verify that the practitioners it certifies are posted to registered facilities. Before writing any integration code, the licensing team must sign an agreement, attend a kickoff, and read a PDF listing the fields, codes, and endpoints. The PDF was last refreshed nine months ago and nobody is sure whether it still matches the runtime.
The problem
Section titled “The problem”The registry exists. What it offers is not published anywhere a tool can read.
An integrator cannot answer the basic questions from a stable source: which registry exists, who owns it, which entities and fields are available, which services it supports, which policies apply, which evidence a caller can request. The institution may be willing to collaborate. The capability is still hard to discover when the access route, schema, policy, and evidence options live only in PDFs, meeting notes, and the memory of two engineers.
Why it matters
Section titled “Why it matters”When discovery happens by meeting, the first technical decision is made before any technical artifact exists. The integration team estimates work from rumour, scopes it from a slide deck, and writes code that turns the rumour into an assumption inside production.
A reviewer only meets the integration after that. The questions a reviewer would have caught early (“is this field the authoritative one? does this policy actually allow this purpose?”) arrive when the answer would require a refactor.
Why common approaches stall
Section titled “Why common approaches stall”PDF catalogues and API guides are useful for orientation. They stall the moment a workflow tool, an integration testing harness, or a review workbench needs structured facts: schema links, policy links, service requirements, evidence types, endpoints. Nothing reads a PDF as a contract.
Central service catalogues can help an institution find which systems exist. They stall when the registry-specific details (which entities, which fields, which evidence is offered) remain outside the catalogue or drift out of sync with the actual runtime.
A Swagger UI on the API lists endpoints and parameters. It stalls when reviewers ask about policy, codes, evidence shapes, or who the data owner is, because OpenAPI alone does not describe any of those.
What Registry Stack changes
Section titled “What Registry Stack changes”The questions get answers tools can read.
Registry Manifest renders the registry’s description as a portable publication bundle: catalogue entries, service descriptions, schemas, policies, and evidence-offering metadata, each in a standard form a reviewer or a tool can consume.
Registry Relay exposes metadata routes alongside the data routes, so a caller can fetch the description that matches what the runtime actually serves.
Registry Atlas fetches, classifies, and inspects those published artifacts. The licensing team can answer “what does this registry offer?” before requesting the meeting.
The meeting still happens. The meeting is now about purpose, scope, and timeline, not about which fields exist. For the broader model, see the architecture overview.
What is built today
Section titled “What is built today”Registry Manifest documents renderers for DCAT, BRegDCAT-AP, CPSV-AP, SHACL, JSON Schema, ODRL policy documents, OGC API Records item bodies, and evidence-offering metadata. Registry Relay documents metadata routes and scope-controlled access. Registry Atlas documents a service-first inspection model for published artifacts.
See the publishing pipeline, Registry Manifest overview, and Registry Atlas overview.
What is future-facing or out of scope
Section titled “What is future-facing or out of scope”Registry Stack does not promise a universal catalogue of all registries. It provides a way for a registry or registry programme to publish and inspect its own metadata.
Dynamic partner onboarding, cross-government discovery governance, and automatic approval of access requests remain deployment and governance concerns.