Skip to content

Service registry

The master data for every government service: a CPSV-AP-compatible "service passport", its version history, the evidence catalogue, a life-event layer, and once-only violation detection.

UI: /admin/registry/services, /admin/registry/evidences.

Where the model comes from

Component Source
Service passport EU CPSV-AP plus the Kazakh "standard"
Life events Singapore LifeSG, Korea Government24
Evidence ↔ registry mapping Estonian once-only principle
Progress vs. outcome split Dutch ZGW

The service passport

registry_services maps onto the core CPSV-AP properties: name, description, competent authority, legal resource, target group, output, channel, cost, processing time, status and life event.

Key constraints:

Field Values
fulfilment auto · manual
output_type Declaration · Physical object · Code …
assurance_level low · substantial · high
lifecycle active · deprecated · withdrawn
proactivity information · online · once_only · proactive

Endpoints

Reads (registry.view)

Endpoint What
GET /v1/registry/overview Registry overview — counts, violations
GET /v1/registry/catalog Internal catalogue
GET /v1/registry/services Service list
GET /v1/registry/services/{id} Passport
GET /v1/registry/services/{id}/versions Version history (delta vs. baseline)
GET /v1/registry/services/{id}/once-only Violations for this service
GET /v1/registry/evidences Evidence catalogue
GET /v1/registry/life-events Life and business events
GET /v1/registry/once-only All once-only violations

Writes (registry.manage)

Endpoint What
POST /v1/registry/services New passport
PUT /v1/registry/services/{id} Edit (creates a new version)
POST /v1/registry/services/{id}/publish Publish — appears in the catalogue
POST /v1/registry/services/{id}/archive Archive
DELETE /v1/registry/services/{id} Delete
PUT /v1/registry/services/{id}/evidences Set required evidence
POST/PUT/DELETE /v1/registry/evidences[/{id}] Evidence catalogue
POST/DELETE /v1/registry/life-events[/{id}] Life events

Public catalogue

Endpoint What
GET /v1/catalog/services · /services/{id} Only published rows
GET /v1/catalog/life-events Grouped by event

Once-only violations

The principle: a citizen must not be asked again for a document the state already holds.

Detection lives in the registry_once_only_violations view:

evidence.from_citizen = true   (we ask the citizen for it)
        AND
evidence.in_khur      = true   (the registry already has it)
        ↓
    once-only VIOLATION

Every violation carries khur_service_code, which says how to obtain that data from the state registry — so the fix is concrete: stop asking the citizen and pull the lookup instead.

Where to see it

Admin → Registry → Overview shows the total and a per-service breakdown. The sample seed data produces 6 violations, so the platform is exercisable from day one.

Why no RLS?

Registry tables are not per-user; they are organisational master data (the same category as the gateway and relay tables). Protection is at the HTTP layer instead:

  • Every write / management endpoint requires registry.manage.
  • The public catalogue only exposes rows with status = 'published'.

Version history

registry_service_versions stores each passport change as a delta against the baseline, which answers "when and how did this service's requirements change?"