Speculative extensions and design explorations that build on the core platform. These are ideas under consideration, not current features.
Departments author a single structured service description, and it is published automatically to every channel — web, API, phone script, AI agent, PDF, email.
Today, a single government service like Apply for Universal Credit exists as multiple parallel descriptions, each maintained by a different team: a GOV.UK web page, PDF and paper forms, phone script guidance, internal caseworker guidance, and API documentation. When eligibility rules change, five teams update five descriptions. They drift. Citizens get different answers depending on the channel.
Now add AI agents as a sixth channel, and the problem compounds.
Describe your service once, in a structured service description. From that single description, generate every channel automatically. Departments author structured truth. The platform generates channel-specific outputs. When something changes, departments update one place. Every channel reflects the change immediately.
Each service is described across four dimensions. These are already defined in the current platform for AI agents — the publish-once model extends them to every channel.
What the service is: name, department, eligibility summary, data it needs, SLA, complaint routes, escalation contacts. The service’s identity card.
Who is eligible and why: machine-readable rules with human-readable failure reasons. “You must be over 16”, “You must have a valid driving licence”. Edge cases documented.
What the journey looks like: a step-by-step map from “not started” to “completed”. Which steps are required, which are optional, what unlocks what. The service’s choreography.
What data is shared and why: every piece of data the service needs, who it comes from, what it’s used for, how long it’s kept, and how to revoke. The service’s data contract.
From the same service descriptions, the platform generates channel-specific outputs for every delivery surface.
| Channel | What it generates | Status |
|---|---|---|
| AI agent (MCP) | Tools, resources, prompts for Claude/GPT | Built |
| Web form (GOV.UK Forms) | Pages, questions, routing, confirmation | Feasible |
| API (OpenAPI 3.0) | REST endpoints, request/response schemas | Straightforward |
| Service catalogue | Schema.org/GovernmentService + DCAT entry | Trivial |
| Notifications (GOV.UK Notify) | Email/SMS templates per journey stage | Feasible |
| Accessible summary (HTML/print) | Printable service overview page | Feasible |
Publish once is not a departure from existing government digital standards. It is a direct implementation of them.
One source of truth means citizens get the same answer whether they use the web form, the AI agent, or the phone script generated from the same description.
Service descriptions are JSON, output includes OpenAPI 3.0, Schema.org, DCAT. Every format is machine-readable and standards-based.
The generator layer is reusable across all departments. Build once, use 1,544 times.
OpenAPI 3.0 is the government-mandated format. The platform generates compliant specs automatically from service descriptions.
Three countries have demonstrated, at national scale, that government services are data — not websites.
929 institutions, 3,000+ digital services, two decades of secure decentralised data exchange. X-Road proved that services can be described as interoperable, machine-readable specifications and federated across organisations.
Composable modules — identity, payments, notifications — assembled into services. MyInfo’s deployment time dropped from one year to four months. “Describe once, compose everywhere” at national scale.
23 million users, 130+ services. Diia.AI launched September 2025 as the world’s first government AI agent delivering real services via MCP. Ukraine coined the term “Agentic State”: citizens express intent, AI executes.
13 standard service shapes have been identified across 1,544 government services. Each shape comes with a pre-built state model template — the skeleton of the journey. Departments select the closest shape, then customise.
| Type | What it means | Example services |
|---|---|---|
| Benefit | Citizen seeks financial support; income-assessed | Universal Credit, PIP, Housing Benefit |
| Application | Submit information, receive a decision | Passport, Child Benefit, Blue Badge |
| Licence | Prove permission to do something | Driving licence, fishing licence |
| Obligation | Something the citizen must do | Update DVLA address, notify OPG of death |
| Legal process | Navigate complexity with professional support | Probate, LPA, divorce |
| Portal | Access multiple services through one account | UC journal, student loans |
Plus 7 more shapes covering registrations, entitlements, grants, payments, appointments, task lists, and information hubs. Departments don’t design service journeys from scratch — they select a shape, fill in the specifics, and the platform generates the journey for every channel.
Describing services as data is not the end state. It is the precondition for three capabilities that are currently impossible.
Proactive services — if a citizen’s circumstances change (recorded through one service), the platform can identify other services they’re now eligible for and notify them automatically.
Life event orchestration — 16 life events have been mapped across all 1,544 services. When a citizen experiences a birth, bereavement, job loss, or retirement, the platform identifies all relevant services and sequences them.
Departmental analytics — when services are described as data, departments can measure coverage, identify gaps, compare interaction patterns, and understand where citizens get stuck.
Four distinct UI paradigms were explored for the citizen app. Each addresses a fundamental question: what should your relationship with government look like on a phone?
The current app uses a traditional four-tab structure: Home, Chat, To-do, and Wallet. Despite having transformational agentic capabilities — life event detection, cross-service field merging, delegated action, proactive eligibility — the interaction model still organises itself around government’s taxonomy. Services live in one tab, conversations in another, tasks in a third. The agentic loop is fractured across views.
You open the app and see your life — your family, your money, your health, your vehicles. Government is invisible infrastructure. The app mirrors your life back to you, organised into facets. Data-driven alerts surface what needs attention. Conversations open from data points and live inside your life facets, with the depth and persistence of full threads. Life event journeys unfold as swipeable stories.
Conversations are the entire app. Your relationship with government is a series of threads — some brief, some spanning months. Plans, tasks, credentials, and consent all live inside conversations, not in separate tabs. There is no service directory because you never browse; you just talk. The agent initiates threads proactively when something needs attention.
A living, intelligent feed. No pages to navigate to — just a single stream of cards representing everything happening in your relationship with government. Active journeys appear as stories at the top. Priority items are pinned. Everything else flows through a timeline. Every card is actionable, and any card can expand into a conversation.
Your life is the home screen. Conversations live inside facets with full depth. Life events unfold as swipeable stories.
Best when citizens have complex, ongoing needs. The conversation is the relationship.
Best when immediacy matters. Everything is one scroll away. No navigation decisions.
Traditional four-tab structure. Familiar but fractures the agentic loop across separate views.
The recommended model is a hybrid that takes the strongest idea from each: identity-first organisation from the Mirror, conversation depth from the Journal, story progression for life events from the Stream. The organising principle is simple: your life comes first, government wraps around it.