Designing Legible Government Services

The four structured documents that make a service machine-readable. This is the core of what your department will author.

Every transactional government service publishes four artefacts. Together, they form a complete contract between your department and any authorised agent. The agent reads these artefacts, not web pages. It evaluates eligibility from your policy, follows transitions from your state model, requests consent as specified in your consent model, and presents your service to the citizen using metadata from your manifest.

1a. The Manifest

The manifest is where you start. It is the simplest artefact to author because it describes information your department already knows: the service name (as citizens should see it), the responsible department, the jurisdictions it applies to, what it costs, how long it takes, and the complaint and appeal routes.

What it tells the agent: "This service exists. It belongs to DVLA. It costs £14. It takes 10 working days. It is available in England, Wales, and Scotland. If the citizen wants to complain, here is the URL. If they want to appeal, here is the process. The data controller is DVLA and the lawful basis is public task."

What product teams decide:

• Service name — The citizen-facing name. "Renew Driving Licence", not "DL-RENEW-001".
• Jurisdiction boundaries — Does this apply in Scotland? Northern Ireland? Different rules may mean separate artefacts.
• Fee structure — Amount, currency, exemptions (e.g. over-70 renewals are free).
• SLA commitments — What turnaround time can you guarantee?
• Redress routes — Complaint URL, appeal process, relevant ombudsman.
• Audit requirements — Data retention period, controller, lawful basis under UK GDPR.

{
  "name": "Renew Driving Licence",
  "department": "DVLA",
  "jurisdiction": "England, Wales, Scotland",
  "constraints": {
    "sla": "10 working days",
    "fee": { "amount": 14, "currency": "GBP" },
    "availability": "24/7 online"
  },
  "redress": {
    "complaint_url": "https://www.gov.uk/complain-about-dvla",
    "appeal_process": "Contact DVLA directly",
    "ombudsman": "Parliamentary and Health Service Ombudsman"
  },
  "audit_requirements": {
    "retention_period": "7 years",
    "data_controller": "DVLA",
    "lawful_basis": "Public task"
  }
}

1b. The Policy Ruleset

The policy ruleset is a list of conditions that must all pass for a citizen to be eligible. Each rule operates on a single data field using a simple operator: >=, <=, ==, !=, exists, or in. If a rule fails, the agent shows the citizen the reason_if_failed message — in plain English, written by your team.

What it tells the agent: "Evaluate these rules against the citizen's data. If all pass, proceed. If one fails, explain why and, where possible, redirect to an alternative service."

Two powerful fields make policies more than just gatekeepers:

• alternative_service — When a rule fails, point the citizen to the right place. "You need an existing licence to renew" becomes actionable: "Would you like to apply for a provisional licence instead?"
• triggers_handoff — Some failures are too complex for automated handling. A revoked licence requires human review. The handoff flag routes the citizen to a caseworker with full context.

Edge cases are named situations that do not fit the standard flow. They have detection criteria and defined actions. Your team decides what counts as an edge case. A common pattern: "If the applicant is over 70, the renewal is free but requires a medical self-declaration." This is not a rejection — it is an alternative path.

{
  "rules": [
    {
      "id": "age-minimum",
      "description": "Applicant must be at least 16",
      "condition": { "field": "age", "operator": ">=", "value": 16 },
      "reason_if_failed": "You must be at least 16 to hold a driving licence"
    },
    {
      "id": "has-licence",
      "condition": { "field": "driving_licence_number", "operator": "exists" },
      "reason_if_failed": "You need an existing licence to renew.",
      "alternative_service": "dvla.apply-provisional-licence"
    },
    {
      "id": "not-revoked",
      "condition": { "field": "licence_status", "operator": "!=", "value": "revoked" },
      "reason_if_failed": "Your licence has been revoked.",
      "triggers_handoff": true
    }
  ],
  "edge_cases": [
    {
      "id": "medical-condition",
      "detection": "medical_conditions",
      "action": "Route to medical assessment. DVLA form C1 required."
    },
    {
      "id": "over-70",
      "detection": "over_70",
      "action": "Over-70 renewal is free but requires medical self-declaration."
    }
  ]
}

1c. The State Model

The state model defines the valid sequence of states and transitions for a service interaction. It is a directed graph with a single entry point (not-started) and one or more terminal states (completed, rejected, handed-off). Every state has a type: initial, intermediate, or terminal. Every transition has a from state, a to state, a trigger, and an optional condition.

What it tells the agent: "The citizen is currently at state X. The valid next states are Y and Z. To reach Y, the trigger 'consent granted' must fire. To reach Z, the trigger 'consent denied' must fire. There are no other options."

What product teams decide: The states, the order, and the branching logic. Start with the happy path. Then ask: what if they are not eligible? What if there is a medical complication? What if they refuse consent? Each of these becomes a branch in the state model.

The state model is enforced deterministically. The agent cannot advance to "payment-made" unless "photo-submitted" has been reached. It cannot reach "completed" without "application-submitted". This is the guarantee that the system is auditable: every journey follows the published state model, and every transition is logged as a trace event.

1d. The Consent Model

The consent model defines every data-sharing grant the service requires. Each grant has: an ID, a description (shown to the citizen), the specific fields being shared, the source of those fields, the purpose of the sharing, the duration, and whether it is required or optional.

What it tells the agent: "Before proceeding, you must obtain consent for these specific data-sharing grants. Show each grant to the citizen with its purpose and source. Required grants cannot be skipped. Optional grants can be declined without blocking the journey."

What product teams decide:

• Which data fields does your service actually need? (Minimise — only what is necessary.)
• Where does each field come from? (GOV.UK One Login, HMPO, HMRC, citizen-entered.)
• What is the lawful purpose of each sharing? (Write this in plain English.)
• How long do you need the data? (Session, duration of application, or ongoing.)
• What happens if the citizen revokes consent mid-journey?

{
  "grants": [
    {
      "id": "identity-verification",
      "description": "Verify your identity using GOV.UK One Login",
      "data_shared": ["full_name", "date_of_birth", "national_insurance_number"],
      "source": "one-login",
      "purpose": "To confirm you are who you say you are",
      "duration": "session",
      "required": true
    },
    {
      "id": "photo-sharing",
      "description": "Share your passport photo with DVLA",
      "data_shared": ["passport_photo"],
      "source": "hmpo-passport-office",
      "purpose": "DVLA will use your most recent passport photo for the new licence",
      "required": true
    }
  ],
  "revocation": {
    "mechanism": "Contact DVLA or revoke through your GOV.UK account",
    "effect": "Application will be cancelled if consent is revoked before completion"
  }
}

The single most important architectural idea in the system. The language model generates conversation; deterministic code makes every decision that matters.

Using a language model in government creates an obvious question: how do you prevent it from making mistakes that affect people's lives? The answer is the deterministic boundary — a strict separation between what the language model does and what code does.

What the language model handles

• Natural language understanding — Interpreting "my mum just died" as a bereavement life event.
• Conversational framing — Explaining eligibility results, consent requests, and outcomes in plain English.
• Empathetic tone — Adjusting language for sensitive situations (bereavement, disability, financial hardship).
• Clarification — Asking follow-up questions when the citizen's situation is ambiguous.

What deterministic code handles

• Policy evaluation — Eligibility decisions are evaluated deterministically from the policy ruleset. The language model never decides whether someone is eligible.
• State transitions — These follow the state model. The model cannot skip, reorder, or invent steps.
• Consent enforcement — Grants are shown exactly as defined. The model cannot add, remove, or modify consent requirements. It never bypasses consent.
• Data submission — The model never sends data to a department API directly. All submissions go through a deterministic capability invoker and require explicit citizen approval.
• Service discovery — The service graph determines which services are relevant. The model presents them but does not invent connections.

The processing pipeline

Every interaction follows a pipeline where the language model and deterministic code have clearly separated responsibilities.

The orange boxes are where the language model operates: understanding what the citizen said, and composing a natural-language response. The green boxes are where deterministic code operates: checking eligibility, moving through the state model, enforcing consent, and submitting data. The language model is sandboxed — it can generate conversational text, but all actions (state changes, data sharing, API calls) are mediated by the deterministic runtime.

If the model suggests something that contradicts the artefacts, the runtime blocks it. If the model tries to skip a state, the state machine rejects the transition. If it tries to submit data without consent, the consent manager blocks it. If it generates an eligibility assessment that differs from the policy evaluation, the deterministic result takes precedence. The model is a communicator, not a decision-maker.

Practical implications for service design

• Your artefacts are the authority. The language model operates within the constraints you set. If your state model says identity verification must precede eligibility checking, that is an invariant.
• The model communicates, it does not decide. It translates policy evaluation results into plain English. It explains why someone is or is not eligible. But the actual evaluation happens in code, against the rules you wrote.
• Every action is auditable. Because all decisions go through deterministic code, every policy check, state transition, and consent event is logged as a structured trace event. The language model's conversational output is also logged, but it is not the decision record.
• Errors are traceable. If a citizen is incorrectly assessed, the investigation starts with the policy ruleset and the data that was evaluated. The language model is not a variable in the decision chain.

How services relate to each other, how citizens discover them, and how the agent builds cross-departmental plans.

Life events as entry points

Citizens do not think in terms of departments or service names. They think in terms of life events: "my mother has died", "I am having a baby", "I am leaving the army." The service graph maps 16 life events to the government services relevant to each. When the agent identifies a life event during triage, it looks up all associated services and builds a plan.

The mapped life events include: bereavement, having a baby, moving house, starting a business, retiring, becoming a carer, leaving prison, arriving in the UK, becoming disabled, divorce, starting university, redundancy, turning 16, turning 18, leaving the armed forces, and adopting a child.

Each life event is mapped to between 3 and 15 government services across multiple departments. Bereavement, for example, connects to death registration (GRO), probate (HMCTS), bereavement support payment (DWP), estate notification (HMRC), pension cessation (DWP), council tax adjustment (local authority), and more. The power of the service graph is that a single conversation can identify and sequence all of these, rather than the citizen having to know about each one independently.

For your department: When you publish artefacts for a service, you also specify which life events it belongs to. This is how the graph is built. If your service is relevant to bereavement but you have not tagged it, the agent will not include it in bereavement plans — and citizens will miss it. Life event mapping is as important as the artefacts themselves.

Edge types: how services connect

Proactivity metadata

Each service in the graph carries proactivity metadata that tells the agent how to present it:

• Mode: suggest (optional, citizen might benefit), warn (important, citizen should know), inform (for awareness, no action needed).
• Priority: Numeric ordering within the plan. Higher priority services appear first.
• Framing: How the agent introduces it. "You may be entitled to..." for benefits versus "You are required to..." for obligations versus "You should be aware that..." for informational items.

Auto-skip logic

When persona data shows a service is clearly irrelevant, it is removed from the plan with a human-readable reason. Example: "Council Tax Reduction has been removed from your plan because you do not pay Council Tax (your property is in a council-tax-exempt category)." The citizen can see what was skipped and why. Nothing is hidden.

Service discovery strategies

The system supports both conservative and expansive approaches to service discovery. A conservative strategy includes only services where the citizen clearly meets the eligibility criteria based on known data. An expansive strategy includes services where the citizen might be eligible, prompting them with questions to determine relevance. Departments can specify which approach suits their service: benefits that citizens commonly miss may warrant an expansive strategy, while services with strict prerequisites may work better with a conservative approach.

Service types

Services are classified by type, which affects how the agent presents them and what artefact complexity to expect:

• benefit — Financial support the citizen receives (UC, Child Benefit, PIP)
• obligation — Something the citizen must do (Self Assessment, jury service notification)
• registration — Recording a fact (death registration, birth registration)
• application — Requesting something (driving licence, passport, visa)
• legal_process — Court or tribunal proceedings (probate, EHCP tribunal)
• document — Obtaining an official document (death certificate, marriage certificate)
• grant — One-off or time-limited funding (Funeral Expenses Payment, Sure Start Maternity Grant)

When the agent stops and hands to a human. Designed to ensure no citizen is left stranded and no vulnerable person falls through the cracks.

Handoff triggers

The agent escalates to a human when any of the following conditions are met:

• Citizen explicitly requests a human. Always honoured, immediately, with no resistance or persuasion to stay automated.
• Safeguarding keywords detected. Language indicating distress, self-harm, domestic violence, or abuse triggers immediate escalation with the highest urgency level.
• Policy edge case. The citizen's situation falls outside the automated rules. The policy ruleset flags this with triggers_handoff: true.
• Repeated failures or confusion. If the citizen is struggling to complete a step or expressing frustration, the agent offers human help.
• Case complexity. Multiple interacting edge cases, legal complications, or situations where automated rules cannot produce a confident answer.

The handoff package

When the agent escalates, it does not simply transfer the citizen to a phone queue. It sends a structured handoff package containing everything the human agent needs:

• Citizen identity and urgency level — Who they are and how urgent this is.
• Reason for escalation — The specific trigger, in plain English.
• Steps completed and steps blocked — What has been done and what could not be done.
• Data collected so far — All fields gathered during the journey, with sources.
• All trace events and receipts — The full audit trail of the interaction.
• Suggested next actions — What the system thinks should happen next (advisory, not binding).

The human agent can pick up exactly where the automated agent left off. The citizen does not have to repeat their story or re-enter their data.

Urgency levels

Designing handoff into your state model

Your state model should include handed-off as a terminal state, reachable from any state where automated processing might fail. For each transition to handed-off, specify the trigger condition in plain language. Examples:

• "Medical condition declared" → DVLA medical assessment team
• "Estate above IHT threshold" → HMCTS probate caseworker
• "Appeal requested" → tribunal administration
• "Citizen requests human" → general department helpline

The handoff destination (phone number, email, team name, opening hours) is specified in the manifest under the handoff field. Ensure this information is kept current. A handoff to a phone line that has been decommissioned is worse than no handoff at all.

For your department: Review your current phone and email escalation paths. Which ones should the agent be able to route citizens to? Ensure each has a clear name, contact details, and hours of operation in your manifest. If your department has specialist teams (medical assessments, complex cases, fraud), these should be separate handoff destinations with appropriate routing conditions.

How citizens experience government through an AI agent. Two modes, one continuous conversation.

When a citizen opens the GOV.UK app and speaks to their agent, the conversation operates in one of two modes. Understanding these modes is useful context for designing services that work within the agentic model.

Triage mode

An open-ended conversation where the citizen describes their situation in their own words. The agent identifies the life event (bereavement, having a baby, starting a business), proposes relevant services across all departments, and builds an ordered plan with dependencies. No single service context — the whole of government is in scope.

Journey mode

Focused on completing one service. The agent collects data using structured cards, obtains consent with named grants, advances through the service's state model with deterministic progression, and delivers a concrete outcome with a receipt. Every step is auditable.

The two modes switch naturally. Triage proposes a plan; the citizen accepts it; journey mode begins for the first service. When that journey completes, the agent returns to the plan and moves to the next service. If the citizen mentions something unexpected mid-journey ("actually, I also need to update my address"), the agent can briefly re-enter triage mode before resuming.

The end-to-end flow

Why this matters for service design: Your service does not control when or how a citizen arrives. They may come via a life-event triage ("my mother has died") or directly ("I need to renew my driving licence"). Your artefacts must support both paths. The manifest tells the agent what your service does; the policy tells it who is eligible; the state model tells it what steps to follow. The agent handles the conversation around these structures.

Eight personas that exercise different cross-sections of services, relationships, and edge cases. Use them to test your artefacts.

Each persona represents a real pattern of need. They are designed to stress-test the system across departmental boundaries, surface edge cases, and ensure no common citizen journey is broken. When you author artefacts for your department, pick the personas whose life events touch your services and walk through the journey end to end.

What each persona exercises

Sarah Okafor exercises the most complex cross-departmental journey: bereavement. Four departments, strict sequencing (death must be registered before probate can begin), and the emotional sensitivity of a citizen dealing with loss while navigating bureaucracy. Tests: multi-department plans, REQUIRES edges, handoff for IHT complexity, delegation (executor acting on behalf of the deceased's estate).

Amina Hassan exercises the immigration and settlement pathway. Tests: language accessibility, right-to-work verification, the NI number as a prerequisite for everything else, and how the system handles a citizen with very little existing data (no Tier 1 credentials initially).

Marcus Taylor exercises time-critical services with legal constraints. Tests: the 28-day housing deadline after release, DBS disclosure complexity, how the system handles a citizen who may have limited digital access and needs frequent handoffs.

Priya Anand exercises the parenting services cluster. Tests: ENABLES edges (child benefit enables tax-free childcare), the maternity pay/allowance distinction (edge case in DWP policy), and UC interactions with other benefits.

James Whitfield exercises the special educational needs and disability pathway. Tests: the EHCP tribunal process (legal_process service type), appeals, PIP assessment edge cases, and how the system handles services where outcomes are uncertain and timescales are long.

Daniel Obi exercises HMRC self-employment services. Tests: Making Tax Digital obligations, quarterly reporting cycles, VAT threshold edge cases, and how the system presents obligations (things you must do) differently from benefits (things you can claim).

Zara Begum exercises first-time interactions. Tests: how the system handles a citizen with no existing government data, no prior service history, and potentially low confidence in dealing with official processes. Everything must be clear, nothing assumed.

Fatima & Tomasz Nowak exercise the household model. Tests: delegation between family members, EU licence exchange (DVLA), the High Income Child Benefit Charge (a cross between HMRC and DWP), and how the system handles multiple children with different service needs.

Designing new personas for your department

You should create personas specific to your department's services. A good persona includes:

• A life event — What is happening in this person's life?
• At least two services from your department — To test sequencing and data sharing between them.
• A cross-departmental dependency — At least one service from another department that is required or enabled by yours.
• An edge case — A situation that pushes the boundaries of your policy rules.
• A delegation relationship — Someone acting on behalf of someone else: a carer, an executor, a parent, a legal representative.