Government services

The citizen-facing service surface: pick a service from the catalogue, file an application, have an officer review it, and receive certificates, payments and appointments — the full cycle. UI: /me/services, /me/applications, /manager/requests.

Application lifecycle

The model follows the Dutch ZGW lesson and keeps progress (status) and outcome (result) separate — "rejected" says the case is closed but not why.

stateDiagram-v2
  [*] --> submitted: citizen files
  submitted --> registered: formally registered (SLA starts)
  registered --> in_review: officer picks it up
  in_review --> info_required: more evidence requested
  info_required --> in_review: citizen supplies it
  in_review --> approved: approved
  in_review --> rejected: rejected
  approved --> completed: output issued
  submitted --> cancelled: citizen withdraws
  info_required --> expired: deadline passed

Progress (status)	Meaning
submitted	Filed by the citizen
registered	Formally registered — the SLA starts here
in_review	Under review
info_required	Waiting for additional evidence
approved · rejected	Decided
completed	Output (certificate / document) issued
cancelled · expired	Withdrawn / timed out

Outcome (result)	Meaning
granted	Granted
refused	Refused
withdrawn	Withdrawn by the citizen
not_admissible	Cannot be accepted
processed	Processed without a decision (automatic)

Citizen endpoints

Endpoint	What
GET /v1/gov/services · /life-events	Catalogue, life events
GET /v1/gov/overview	My overview (applications, notifications, payments)
GET /v1/gov/applications	My applications
POST /v1/gov/applications	File a new one
GET /v1/gov/applications/{id}/timeline	History
POST /v1/gov/applications/{id}/provide-info	Supply evidence
POST /v1/gov/applications/{id}/cancel	Withdraw

Writes are rate limited to ~30/min; every row is protected by the RLS self policy.

Officer queue

Requires gov.review. UI: /manager/requests.

Endpoint	What
GET /v1/gov/officer/stats	Workload figures
GET /v1/gov/officer/queue	The queue
GET /v1/gov/officer/queue/{id}	Application details
POST /v1/gov/officer/queue/{id}/assign	Assign to myself
POST /v1/gov/officer/queue/{id}/request-info	Ask for evidence
POST /v1/gov/officer/queue/{id}/decide	Decide (approve / reject + result)
POST /v1/gov/officer/queue/{id}/complete	Issue the output and close

The officer RLS policy

Besides self · admin · service, the gov_* tables carry an officer policy. A caseworker only sees the applications that concern them — even a buggy query cannot expose other citizens' data.

Certificates

Endpoint	What
GET /v1/gov/references	Issued certificates
POST /v1/gov/references	Create one (as a service output)

A certificate is one form of output produced when an application reaches completed. Where required it is issued as a PDF with a PAdES signature.

Notifications

Endpoint	What
GET /v1/gov/notifications	List
POST /v1/gov/notifications/{id}/read	Mark one read
POST /v1/gov/notifications/read-all	Mark all read

A notification is created on every status transition. UI: /me/notifications.

Payments

Endpoint	What
GET /v1/gov/payments	Payment list
POST /v1/gov/payments/{id}/pay	Pay

UI: /me/payments. Payment rows attach to an application; once paid, the workflow continues.

Appointments

Endpoint	What
GET /v1/gov/appointments	My appointments
POST /v1/gov/appointments	Book
POST /v1/gov/appointments/{id}/cancel	Cancel

UI: /me/appointments.

Managing the catalogue

Catalogue entries (gov_services, gov_life_events) originate in the service registry, where the passport, versions and evidence requirements live. See Service registry.

The public read surface:

Endpoint	What
GET /v1/catalog/services	Published services
GET /v1/catalog/services/{id}	Details
GET /v1/catalog/life-events	Grouped by life event

Editing the catalogue requires gov.catalog or registry.manage.

Forwarding to downstream agencies

When one application concerns several agencies, the relay module handles it — assignment with SLAs and follow-up tracking. See Request relay.