---
title: "GovOps"
slug: govops
category: industry
term_status: ambiguous
evidence_status: verified
summary: "This page reads GovOps as running government digital services under public-value constraints: everyone must be served, decisions must be lawful and open to appeal, public money is spent under procurement rules, and performance is published. Officially, GovOps names US state agencies and a federal catalogue."
audience: [Public-sector service teams, Digital and operations leaders, Govtech vendors and contractors, Policy and legal staff, Beginners]
last_verified: 2026-10-23
key_takeaways:
  - "GovOps is not a recognised discipline. Officially it is the short name of California's Government Operations Agency (2013), Utah's Department of Government Operations (2021) and a GSA shared-services marketplace. This page's reading, running government digital services, is an editorial emphasis."
  - "What makes government operations different is five public-value constraints: a mandate (people cannot go elsewhere), universal access, lawful and appealable decisions, public money under procurement rules, and transparency."
  - "Without a market, there are no churn or revenue signals, so the service has to build its own feedback: completion by channel, assisted-route outcomes, complaints, appeals and overturn rates."
  - "Count every channel: GOV.UK computes digital take-up and cost per transaction across all channels (help with the online service still counts as digital), so closing a phone line can make the numbers look better while excluding people."
  - "Automated decisions are the highest-stakes area. After Robodebt, Australia's Attorney-General's Department warned that harm can build up before complaints and appeals stop it; this page reads the Dutch childcare-benefits case the same way."
  - "The rules are set by each jurisdiction and change with dates (for example, the compliance dates of the US ADA Title II web rule moved to April 2027 and 2028). Treat every legal statement as dated and get your own legal advice."
related: [identityops, procurementops, privacyops, complianceops, decisionops, healthops, eduops, incidentops]
---

## What GovOps is

### In 30 seconds

**GovOps**, as this page uses it, is the practice of **running government digital services**: keeping public services
available, accessible, lawful and improvable after launch, under rules a private company does not face. Officially, though,
"GovOps" is a **name, not a practice**: the short name of the California Government Operations Agency (July 2013, Governor's
Reorganization Plan 2),[^ca-about] whose 15 departments and programmes include the Department of Technology and CalHR (as
listed on 2026-10-23);[^ca-depts] of Utah's Department of Government Operations, formed in 2021 from three
departments;[^utah-about] and of the GovOps Marketplace, a GSA catalogue of shared services for federal agencies.[^gsa-mkt]

**In one line: GovOps here means operating public services when the users cannot leave, the decisions are law, the money is
public and the results are published.** The tools are the same as elsewhere, and this page links to the pages that teach them.

::: note An editorial reading
Searches on 2026-10-23 found no published definition of GovOps as a practice; practitioners say "digital government", "public
digital services" or "service delivery". Reading GovOps as "operating government digital services" is this Atlas's **editorial
emphasis**, not an established usage.
:::

**Who this page is for:** public-sector service teams and leaders, govtech vendors, and policy and legal staff whose rules
become software. Last verified 2026-10-23. Nothing here is legal advice.

### At a glance

| Item | GovOps on this page |
|---|---|
| Goal | Public services that everyone can use, that make lawful decisions people can challenge, that can be changed safely, and whose performance is visible |
| Users | Service owners, delivery teams, operations and support staff, policy and legal teams, commercial leads, auditors |
| Scope | Service standards and assessments, accessibility mandates, assisted and non-digital routes, performance publishing, common components and digital public infrastructure, open code, data and standards, procurement constraints, security and data location, automated decisions, legacy modernisation |
| Jurisdictions covered | Instruments from the UK, the US (federal and state) and the EU; cases add Australia, the Netherlands and Estonia. Others, such as Australia's Digital Service Standard, Canada or India, are not covered |
| Out of scope | The agency meaning (mentioned only); running clouds ([CloudOps](../cloudops/)); identity platforms ([IdentityOps](../identityops/)); the buying process ([ProcurementOps](../procurementops/)); privacy programmes ([PrivacyOps](../privacyops/)); decision-model engineering ([DecisionOps](../decisionops/)) |
| Prerequisites | None. Helpful: basic service design, how a web service is run, and how your jurisdiction makes and reviews administrative decisions |
| Key outputs | A service record, published performance data, an accessibility statement, assisted and non-digital routes, transparency records, contracts with exit plans |
| Term status | **Ambiguous**: official name of US state agencies and a federal catalogue; this page's reading is an editorial emphasis |

### The problem GovOps solves

A company can choose its customers and learn from churn. A government service usually cannot. When the Dutch data protection
authority fined the Tax Administration in 2021, its chair said: "Members of the public don't have a choice; they are forced to
allow the government to process their personal data."[^ap-nl] This Atlas groups the consequences into five **public-value
constraints** (an editorial framework):

1. **Mandate.** People cannot go elsewhere, so churn and lost revenue never warn you; measures must be built on purpose.
2. **Universal access.** The GOV.UK Service Standard asks teams to "avoid excluding any groups within the audience they're
   intended to serve" and to provide "appropriate assisted digital support to cover any gaps".[^uk-p5]
3. **Lawful, appealable decisions.** A benefit award must follow the law and be open to challenge; a wrong rule in code makes
   unlawful decisions at scale.
4. **Public money.** Spending follows procurement and spending-control rules, so lock-in is a fiscal risk.
5. **Transparency.** Performance, code, data and algorithms are increasingly published, and auditors and courts can examine
   them.

**What fails without it.** A launch with no single owner (HealthCare.gov, 2013), benefit systems that could not absorb a surge
(US unemployment insurance in the pandemic), and automated debts without a legal basis (Robodebt). After Robodebt, Australia's
Attorney-General's Department noted that "considerable harm can occur before complaints-based processes such as merits review
and judicial review can put a stop to further unlawful action".[^ag-adm] The [use cases](#use-cases-and-scenarios) examine each.

### What GovOps is not

- **Not the agency.** For California's or Utah's GovOps, see their sites; this page mentions them only to explain the name.
- **Not DevOps with a government logo.** Delivery, monitoring and incidents are taught on [DevOps](../devops/),
  [SRE](../sre/) and [IncidentOps](../incidentops/); GovOps adds the constraints above.
- **Not policy-making.** Policy decides what the service does; GovOps runs it and feeds evidence (such as appeals) back.
- **Not procurement.** Buying belongs to [ProcurementOps](../procurementops/); GovOps cares how contracts limit change.
- **Not a certification or movement.** No body certifies GovOps; the charter and maturity model here are this Atlas's proposals.

::: figure GovOps on this page: public-value constraints over shared engineering practice
```mermaid
flowchart LR
  M["Mandate:<br/>users cannot leave"]:::decision --> S
  U["Universal access:<br/>assisted routes"]:::decision --> S
  L["Lawful decisions:<br/>review and appeal"]:::decision --> S
  P["Public money:<br/>procurement rules"]:::decision --> S
  T["Transparency:<br/>publish, be audited"]:::decision --> S
  S["Operating a<br/>government<br/>digital service"]:::core -- "relies on" --> D["DevOps, SRE,<br/>IncidentOps"]:::neutral
  S -- "relies on" --> I["IdentityOps,<br/>PrivacyOps"]:::neutral
  S -- "relies on" --> B["ProcurementOps,<br/>DecisionOps"]:::neutral
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
```
Text equivalent: Five public-value constraints (mandate, universal access, lawful decisions, public money, transparency)
shape the operation of a government digital service. Arrows labelled "relies on" lead from that service to practice taught
on other pages: DevOps, SRE and IncidentOps; IdentityOps and PrivacyOps; ProcurementOps and DecisionOps.
:::

## Where GovOps comes from and where it sits

### Origins and evolution

**The label** is recent and administrative (California 2013, Utah 2021, the GSA marketplace); there is no history of
"GovOps" as a practice. **The practice** has a documented history under other names:

- **Service standards.** The GOV.UK Service Standard has 14 points, from "Understand users and their needs" to "Operate a
  reliable service".[^uk-std] "If you're developing a transactional service for central government, you must get it
  assessed."[^uk-scope]
- **Playbooks.** The US Digital Services Playbook has 13 plays, including "Structure budgets and contracts to support
  delivery" and "Default to open".[^usds-playbook] Its institutions changed in 2025: Executive Order 14158 renamed the US Digital
  Service the "United States DOGE Service",[^eo14158] and GSA eliminated its 18F consultancy (about 90 staff) as
  "non-critical".[^nextgov-18f] In August 2025, Executive Order 14338 created a National Design Studio with a Chief Design
  Officer in the Executive Office of the President.[^eo14338] Read the playbook as principles, not as evidence that a team
  still applies them.
- **Digital public infrastructure (DPI).** The G20's New Delhi Leaders' Declaration (September 2023) describes DPI as "a set
  of shared digital systems, built and leveraged by both the public and private sectors, based on secure and resilient
  infrastructure" that "can enable delivery of services at societal-scale".[^g20-delhi]
- **Accessibility law** covers public bodies in the UK and the EU and US federal agencies. US state and local governments have
  long had ADA Title II duties; a 2024 rule adds a technical standard, with compliance from 2027 (see
  [quality and compliance](#quality-security-privacy-and-compliance)).

### Glossary and mental model

| Term | Meaning | Why it matters |
|---|---|---|
| Service | Everything a person goes through to get something done, across channels | Ops covers phone, paper and counters, not only the website |
| Transactional service | Users exchange information, money, permission, goods or services, or change a government record (GOV.UK)[^uk-scope] | Triggers a service assessment in UK central government |
| Service owner | The one person accountable for the whole service | Without one, launches fail ([Case 1](#case-1-healthcaregov-launch-and-recovery)) |
| Assisted digital | Help for people to use the online service (by phone, in person, from a friend) | GOV.UK counts transactions completed this way as digital[^uk-takeup] |
| Non-digital channel | Phone, paper or counter where staff record the case outside the online service | Counts against digital take-up |
| Service assessment | Peer review against a service standard | In the UK, by a cross-government panel for larger or shared services[^uk-scope] |
| Common component | A shared platform many services reuse (identity, payments, notifications) | Concentrated risk |
| Automated decision-making (ADM) | A system makes or supports an administrative decision | Errors become unlawful decisions at scale |
| Accessibility statement | A published account of how accessible a site is, with known gaps | Required for public bodies in the EU and the UK |

**Mental model: three loops.** The **delivery loop** (ship, measure, improve) is the one every product team knows. The
**access loop** asks who could not use the service (completion by channel, assisted-route outcomes, complaints). The
**legitimacy loop** asks whether decisions were lawful and fair (appeals, overturns, ombudsman findings, audits). A team that
runs only the first loop can look healthy while failing the other two, the pattern behind most cases on this page.

### How GovOps relates to other Ops

| Neighbouring Ops | Shared scope | GovOps's own focus | When to read the neighbour |
|---|---|---|---|
| [DevOps](../devops/), [SRE](../sre/) | Delivery pipelines, reliability, on-call | Reliability on statutory deadlines; offline fallbacks | To build or run the delivery pipeline and SLOs |
| [IncidentOps](../incidentops/) | Incident command, communication | Public communication, deadline extensions, assisted channels | To set up incident roles and tooling |
| [IdentityOps](../identityops/) | Sign-in and identity proofing | Who is excluded by identity checks, and the fallback route | To run an identity platform |
| [ProcurementOps](../procurementops/) | Contracts and suppliers | How contracts limit change and exit | For the buying process and public procurement rules |
| [PrivacyOps](../privacyops/) | Personal data, impact assessments | Data a citizen cannot refuse to give | To run a privacy programme |
| [DecisionOps](../decisionops/) | Automated decision logic | Lawfulness, appeal and public transparency of decisions | To engineer and govern decision models |
| [ComplianceOps](../complianceops/) | Control evidence, audits | Audits by inspectors general, auditors general and ombudsmen | To automate control evidence (for example FedRAMP) |
| [HealthOps](../healthops/), [EduOps](../eduops/) | Public services in a sector | Cross-sector public-value constraints | For sector-specific obligations |
| [CloudOps](../cloudops/), [WebOps](../webops/) | Hosting and web operations | Data location and continuity requirements | To run the platform itself |

## Principles and operating model

### A proposed charter and principles

No official GovOps charter exists. This charter is **this Atlas's proposal**, drawing on the GOV.UK standard, the US playbook
and the cases on this page.

**Mission.** Run public services so that everyone they are meant for can use them, every decision can be explained and
challenged, and the service can be changed safely when the law or people's needs change.

| Principle | What must stay true | Trade-off accepted |
|---|---|---|
| 1. Serve everyone the service is for | Each online journey has an assisted route to the same outcome | Higher cost per transaction |
| 2. Decisions follow the law | Every rule in code has a legal source and an owner; every decision a review route | Slower rule releases |
| 3. Measure what a market would tell you | Completion, exclusion, complaints and appeals are reviewed | Measurement with no revenue |
| 4. Publish by default | Performance, code and algorithm records are public unless an exception applies | Public scrutiny of mistakes |
| 5. Own the exit | Every contract has a tested exit and portable data | Less vendor convenience |
| 6. Reliability matches the deadline | Capacity planned around statutory dates; channels retired with a plan | Idle capacity; old and new in parallel |

**Non-goals:** take-up for its own sake, replacing caseworkers with automation, picking one cloud.

### Building blocks

A service standard to be assessed against (the GOV.UK 14 points,[^uk-std] or the US federal requirements in OMB memo
M-23-22[^omb-m2322]); a **service record** per service (see the [reference implementation](#reference-implementation));
**common components** for identity, payments and notifications; a **data exchange** layer between registers; a **design
system** (for example the US Web Design System, "The design system for the federal government"[^uswds]); published
**performance data**; **transparency records** (accessibility statement, algorithm records, open code and data); and
**independent assurance** (assessments, auditors, ombudsmen).

### Roles, ownership and RACI

Role titles differ between governments. The roles below are the ones a service needs, whatever they are called.

| Activity | Service owner | Delivery team | Policy and legal | Operations and support | Commercial lead |
|---|---|---|---|---|---|
| Define the outcome and the legal basis | A | C | R | I | I |
| Ship a change to the online service | A | R | C (if rules change) | C | I |
| Change a decision rule | A | R | R (legal sign-off) | C | I |
| Keep the assisted route working | A | C | I | R | I |
| Publish performance data and statements | A | R | C | C | I |
| Run an incident on a deadline day | A | R | C (deadline extension) | R | I |
| Renew or exit a contract | A | C | C | C | R |

R = responsible, A = accountable, C = consulted, I = informed. Assessors are independent of the team. One person is accountable for the whole service, including the offline parts: the US
playbook's sixth play is "Assign one leader and hold that person accountable",[^usds-playbook] and Case 1 shows the cost of
not having one.

### Lifecycle: from discovery to retirement

GOV.UK names five phases: "Discovery, alpha, beta, live and retirement".[^uk-phases] Operations work ends only when the last
channel is retired.

| Phase | Operations questions | Exit evidence |
|---|---|---|
| Discovery | Who must use this, by law? Who will struggle online? Where is the data? | User groups incl. excluded ones; legal basis; system map |
| Alpha | Which shared components can be reused? Which decisions will be automated, and how reviewed? | Component choices; decision inventory |
| Beta | Can it run at the deadline peak? Does the assisted route complete the same transaction? | Peak load test; parity test; first published data; accessibility statement |
| Live | Are completion, exclusion and appeals reviewed? Do contracts have exit plans? | Quarterly review records; exit plans |
| Retirement | Who still uses the old route? Where do records go? | Users moved; records retained; contracts closed |

### Operating model and governance

Four mechanisms govern a public service. They work at different speeds, and a team needs all four:

1. **Spend and standards controls (before money is spent).** In the UK, projects that need Cabinet Office spend approval must
   consider every point of the Technology Code of Practice,[^uk-tcop] and assessment can be a condition of that approval.[^uk-scope]
2. **Peer assessment (at set points in delivery).** A panel checks the service against the standard. In UK central government a
   cross-government panel assesses a service if it is "likely to handle more than 100,000 transactions per year" or if "civil
   servants in more than one organisation will use your service"; a form built on an assured form-building platform with fewer
   than 10,000 transactions a year needs no assessment.[^uk-scope]
3. **Publication (continuous).** Published data invites scrutiny between assessments (see [metrics](#metrics-and-kpis)).
4. **External accountability (after the fact).** Auditors, inspectors general, ombudsmen, regulators and courts: slow and
   powerful, they find what the other three missed, often long after the harm. Design mechanisms 1 to 3 so that 4 finds little.

## Architecture and workflow

### Reference architecture

::: figure Reference architecture of a government digital service
```mermaid
flowchart TB
  W["Online service"]:::core --> CW
  A["Assisted route:<br/>phone, counter"]:::core --> CW
  PA["Paper forms"]:::neutral --> CW
  CW["Case work and<br/>decision rules"]:::core -- "boundary: provider" --> CC["Common components:<br/>identity, payments,<br/>notifications"]:::neutral
  CW --> X["Data exchange<br/>layer"]:::neutral
  CW --> RV["Review and<br/>appeal"]:::decision
  CW --> O["Published outputs:<br/>KPIs, records,<br/>statements"]:::decision
  X -- "boundary: other agency" --> R["Registers and<br/>legacy systems"]:::risk
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
```
Text equivalent: Three channels (online service, assisted route by phone or counter, and paper forms) feed one case-work and
decision-rules layer. That layer uses common components (identity, payments, notifications), reads and writes registers and
legacy systems through a data exchange layer, sends contested decisions to review and appeal, and publishes KPIs, records and
statements. Two edges are labelled as trust boundaries: to common components run by another provider, and to registers held
by another agency. Registers and legacy systems are marked as the main risk.
:::

- **All channels feed one case-work layer.** Separate rules per channel drift apart, and people who need help get a different
  service. The cost: an outage hits every channel, so keep an offline fallback for critical deadlines.
- **Common components** are usually cheaper and better tested: GOV.UK Notify lists 1,764 organisations and 12,927 services (as
  shown on 2026-10-23),[^notify] and GOV.UK Pay reports "70,000+ payments processed every day".[^pay] The trade-off is
  concentration, so each service needs a fallback and a support route to the component owner.
- **Exchange data instead of copying it.** X-Road is "open-source software that enables unified, secure data exchange between
  organisations", used between the Estonian and Finnish population registers.[^xroad] The cost is dependence on another
  agency's uptime.
- **Plan for legacy risk.** GAO found in 2025 that of the 11 US federal legacy systems most in need of modernisation, "Eight of
  the 11 systems use outdated languages" and "seven are operating with known cybersecurity vulnerabilities".[^gao-legacy]
- **Trust boundaries** (the labelled edges). Each crossing to another provider or agency needs an owner, an agreement and
  logging; design details are on [IdentityOps](../identityops/) and [IntegrationOps](../integrationops/).

### End-to-end workflow

::: figure An application from start to decision, with exception paths
```mermaid
flowchart TB
  S["Person starts<br/>an application"]:::core --> Q{"Can they complete<br/>it online?"}:::decision
  Q -- "yes" --> ID{"Identity check<br/>passes?"}:::decision
  Q -- "no" --> AS["Assisted route<br/>completes it"]:::core
  ID -- "no" --> AS
  ID -- "yes" --> RU["Rules applied<br/>to the case"]:::core
  AS --> RU
  RU --> AU{"Automated decision<br/>adverse to the person?"}:::decision
  AU -- "no" --> DN["Decision and<br/>notification"]:::core
  AU -- "yes" --> HR["Human review before<br/>issue (proposed)"]:::risk
  HR --> DN
  DN --> AP{"Person<br/>challenges it?"}:::decision
  AP -- "yes" --> RV["Review or appeal;<br/>outcome recorded"]:::risk
  AP -- "no" --> M["Measured: completion,<br/>channel, time"]:::neutral
  RV --> M
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
```
Text equivalent: A person starts an application. If they cannot complete it online, or the identity check fails, an assisted
route completes it. Either way the same rules apply. If an automated decision would be adverse, this page proposes a human
review before it is issued. The decision is issued and notified; if the person challenges it, a review or appeal follows and
its outcome is recorded. Every path ends in measurement of completion, channel and time to decision.
:::

**Happy path:** apply online, pass the identity check, and receive a decision with a reason and a way to challenge it.
**Exception paths:**

- **Identity check fails.** Proofing can exclude people without documents or a credit history; the fallback must reach the
  same decision. Proofing itself is on [IdentityOps](../identityops/).
- **Adverse automated decision.** Human review before issue is this page's proposal, not a universal legal rule; the
  rationale is the Robodebt lesson that harm builds up before review catches it.[^ag-adm]
- **Challenge.** Review outcomes are data. A high overturn rate means the original decisions are wrong.

## Practices, frameworks and tools

### Core practices and playbooks

| Practice | Trigger | Owner | Output | Verification |
|---|---|---|---|---|
| Assisted-route parity test | Each release that changes a journey; quarterly | Operations lead | Test record per journey | Staff complete a test case by phone or at a counter |
| Channel-complete measurement | Monthly | Service owner, analyst | Published KPI file | Totals reconcile with case-work counts |
| Rule change control | Any change to eligibility, calculation or risk rules | Policy and legal lead | Change record linked to the legal clause | A reviewer can trace the rule to the law |
| Deadline readiness | 6–8 weeks before a known peak | Delivery and operations leads | Load test, rota, extension playbook | Peak test passes with margin |
| Exit plan | At award; 12 months before renewal | Commercial lead | Exit plan; tested data export | Export restored in a test environment |
| Planned retirement | Low use, contract end, end of life | Service owner | Retirement plan | No users stranded; records retained |

**Strangler modernisation.** Martin Fowler describes "a gradual process of modernization" that "begins with small additions,
often new features, that are built on top of, yet separate to the legacy code base".[^fowler] It suits government because a
big-bang switch-over of a system that pays benefits puts everyone at risk at once; it costs more while two systems run.

### Methods, standards and frameworks

Mandatory rules versus guidance, for the UK, US and EU only, as checked on 2026-10-23. Not legal advice.

| Jurisdiction | Instrument | Status | What it asks of operations |
|---|---|---|---|
| UK central government | Service Standard, 14 points[^uk-std] | Required for assessed services[^uk-scope] | Includes "Define what success looks like and publish performance data", "Make new source code open" |
| UK central government | Technology Code of Practice, 13 points[^uk-tcop] | Used in Cabinet Office spend control | Includes "Make use of open standards", "Define your purchasing strategy" |
| UK public sector | Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018[^uk-a11y] | Law | WCAG 2.2 AA (per GOV.UK guidance); accessibility statement |
| UK | Algorithmic Transparency Recording Standard[^uk-atrs] | "mandatory for all government departments" | Records for in-scope algorithmic tools |
| UK | Procurement Act 2023, rules changed 24 February 2025[^uk-procurement] | Law | Notices on the central digital platform ([ProcurementOps](../procurementops/)) |
| US federal | OMB M-23-22 on the 21st Century IDEA[^omb-m2322] | Policy | Accessible sites; "Secure by design, secure by default" |
| US federal | Section 508[^s508] | Law | Accessible ICT when agencies "develop, procure, maintain, or use" it |
| US state and local | ADA Title II; 2024 web rule, dates moved by a 2026 interim final rule[^ada-guidance][^ada-ifr] | Law | WCAG 2.1 AA by 26 April 2027 (population 50,000+) or 26 April 2028 (under 50,000, and special district governments) |
| EU | Web Accessibility Directive (EU) 2016/2102[^eu-wad] | Law, transposed nationally | Statement, feedback mechanism, monitoring; EN 301 549 |
| EU | Interoperable Europe Act, in force 11 April 2024[^interop-act] | Law | "Mandatory interoperability assessments" |
| International | G20 New Delhi Leaders' Declaration (2023);[^g20-delhi] International Open Data Charter (2015)[^odc] | Voluntary | Shared DPI; "Open By Default" |

::: caution Dates and versions change
In the Justice Department's long-standing view, ADA Title II already covers all services of US state and local governments,
websites included.[^ada-guidance] The 2024 rule added WCAG 2.1 AA as the technical standard, and an interim final rule effective
20 April 2026 moved its compliance dates from 24 April 2026 and 26 April 2027 to those in the table.[^ada-ifr] Laws also name
different WCAG versions (2.2 in UK guidance, 2.1 in the US rule). Check the current text before planning.
:::

### Tooling landscape

Categories first; examples are public platforms checked on 2026-10-23, not recommendations.

| Category | Examples (verified) | Selection criteria | Risks |
|---|---|---|---|
| Design systems | US Web Design System (v3.14.0)[^uswds] | Accessibility evidence, maintenance | "Uses the design system" taken as proof of accessibility |
| Notifications and payments | GOV.UK Notify;[^notify] GOV.UK Pay ("1,500+" live services)[^pay] | Eligibility, letters, reconciliation | One outage affects many services |
| Sign-in and identity | GOV.UK One Login;[^onelogin] Login.gov (GSA), "NIST IAL2-compliant offering" since September 2024[^logingov] | Routes for people without documents | Exclusion of people who fail proofing |
| Data exchange | X-Road[^xroad] | Governance, onboarding cost | Dependence on other agencies |
| Open data catalogues | W3C DCAT 3;[^dcat3] DCAT-US 3.0 for US federal catalogues (v1.1 is legacy)[^dcatus3] | Required fields, harvesting | Stale metadata, broken links |
| Cloud authorisation | FedRAMP, "a standardized approach to security and risk assessment for cloud products and services"[^fedramp] | Authorised offerings | Assuming it covers your configuration |
| Accessibility testing | Automated checkers plus manual tests; in a 2017 GDS test of 143 planted barriers, Tenon found the most errors and warnings (37%) and Asqatasun the most with manual-inspection prompts (41%)[^gds-a11y-tools] | Coverage | A clean scan read as compliance |

### Automation and AI

One wrong rule repeats across every case, so the constraints bite hardest here.

- **Legal basis, review route, explanation.** Robodebt was an Australian "automated debt-recovery system" that averaged a
  year's income to estimate fortnightly earnings; the Commonwealth later admitted its calculations "did not have a proper legal
  basis".[^whiteford] The Royal Commission's recommendation 17.1 asks the Commonwealth to consider a consistent legal framework
  for automation and says that where it is used "there should be a clear path for those affected by decisions to seek
  review", websites should explain "in plain language how the process works", and "business rules and algorithms should be made
  available, to enable independent expert scrutiny".[^robodebt-rc]
- **No irrelevant inputs.** In the Dutch case (Case 3) the DPA ruled: "It is unlawful, and therefore prohibited, to use
  nationality data to assess applications, combat fraud and determine risk".[^ap-nl]
- **Transparency records.** The UK ATRS "establishes a standardised way for public sector organisations to publish
  information" about algorithmic tools.[^uk-atrs]
- **Where AI helps:** drafting guidance, triaging correspondence, searching policy, with a person accountable for the output.
  AI in entitlement decisions brings every obligation above plus model risk ([DecisionOps](../decisionops/)).

## GovOps in practice

### Reference implementation

**Assumptions.** An illustrative local or national service, "apply for a residents' parking permit", with an online route, a
phone route and paper forms. One service owner. It uses shared notification and payment components, and its case data sits in
a decade-old permits system. The artefact is a **service record**: one version-controlled file that answers the questions an
assessor, an auditor or a new service owner will ask. A spreadsheet works too, if it has an owner and a history.

_Example status: YAML syntax-checked by the Atlas validator; illustrative values; not tied to any real service._

```yaml
# service-record.yaml: one per public service; reviewed quarterly
service: residents-parking-permit
owner: {role: Head of Parking Services, deputy: Permits Operations Lead}
legal_basis:
  - instrument: "<local traffic regulation order, clause>"
    rules_in_code: [eligibility.address_in_zone, fee.by_vehicle_band]
channels:
  online: {url: "https://permits.example.gov", status: live}
  assisted:
    phone: {hours: "Mon-Fri 08:00-18:00", completes_same_transaction: true}
    counter: {location: "Civic Centre", completes_same_transaction: true}
  paper: {status: live, retirement_review: 2027-06-30}
components:
  notifications: {provider: shared-notify, fallback: "letters printed in-house"}
  payments: {provider: shared-pay, reconciliation: daily}
  identity: {method: "address and vehicle match", fallback: assisted}
decisions:
  automated:
    - name: eligibility.address_in_zone
      adverse_outcome_review: "human review before refusal is issued"
      transparency_record: "<link to published record>"
  review_route: "internal review within 28 days; then the appeal body"
performance:
  publish: quarterly
  kpis: [completion_rate, digital_take_up, cost_per_transaction,
         user_satisfaction, appeal_overturn_rate, identity_drop_share]
accessibility:
  statement_url: "https://permits.example.gov/accessibility"
  last_reviewed: 2026-09-15
  known_issues: 2
contracts:
  - supplier: "<case-system supplier>"
    ends: 2028-03-31
    exit_plan: {data_export_tested: 2026-05-20, format: csv-and-documents}
legacy:
  - system: permits-db
    risk: "unsupported database version"
    plan: "strangler: new eligibility API first, then case records"
peaks:
  - event: "annual permit renewal window"
    expected_daily_starts: 4000
    load_tested: 2026-08-30
```

**How to use it.** The owner keeps it current; assessors and auditors read it instead of collecting evidence by email. Each
field links to a constraint: `assisted` and `identity.fallback` to universal
access; `legal_basis` and `decisions` to lawful decisions; `contracts.exit_plan` to public money; `performance` and
`transparency_record` to transparency.

### Hands-on labs

#### Lab 1 (beginner): measure a service across every channel

**Objective:** compute the GOV.UK mandatory KPIs that can be calculated from counts, plus two checks this page adds, and see
how closing a channel distorts them. **Prerequisites:** Python 3.8 or later; no account, cost or risk; about 30 minutes.

Definitions (GOV.UK service manual): completion rate divides completed digital transactions by all started ones "including
partially completed or failed ones";[^uk-completion] digital take-up divides them by "the total number of transactions from all
channels in the same period".[^uk-takeup] Both count assisted digital transactions as **digital**. Cost per transaction divides
the cost "through all channels" by completed transactions.[^uk-cpt] So the data separates `assisted_digital` (staff help
callers through the online service) from `phone` and `paper` (staff record the case in the back office). User satisfaction,
the fourth mandatory KPI,[^uk-kpis] needs survey data and is left out.

_Example status: executed with Python 3.8.10 on 2026-10-23; output below is the real output._

```text
channel,started,completed,cost_gbp,drop_at_identity
online,12500,9000,150000,1400
assisted_digital,700,650,40000,0
phone,1200,1150,80000,0
paper,1300,1200,90000,0
shared_overheads,0,0,60000,0
```

```python
"""Compute channel-complete service KPIs from a quarterly export.

Usage: python3 service_kpis.py service-quarter.csv [appeals_decided appeals_overturned]
Definitions follow the GOV.UK service manual: transactions completed with
assisted digital support count as digital. "phone" and "paper" are non-digital
channels (staff key the case into the back office). The exclusion and appeal
checks are this page's additions.
"""
import csv
import sys

DIGITAL = ("online", "assisted_digital")


def load(path):
    with open(path, newline="") as f:
        rows = {r["channel"]: r for r in csv.DictReader(f)}
    for r in rows.values():
        for k in ("started", "completed", "cost_gbp", "drop_at_identity"):
            r[k] = int(r[k])
    return rows


def kpis(rows):
    digital = [rows[c] for c in DIGITAL if c in rows]
    started_dig = sum(r["started"] for r in digital)
    completed_dig = sum(r["completed"] for r in digital)
    completed_all = sum(r["completed"] for r in rows.values())
    cost_all = sum(r["cost_gbp"] for r in rows.values())
    return {
        "completion_rate": completed_dig / started_dig,
        "digital_take_up": completed_dig / completed_all,
        "cost_per_transaction": cost_all / completed_all,
        "identity_drop_share": rows["online"]["drop_at_identity"]
        / rows["online"]["started"],
        "completed_all": completed_all,
    }


def main(argv):
    rows = load(argv[1])
    k = kpis(rows)
    print(f"Completed transactions (all channels): {k['completed_all']:,}")
    print(f"Completion rate (digital):             {k['completion_rate']:.1%}")
    print(f"Digital take-up:                       {k['digital_take_up']:.1%}")
    print(f"Cost per transaction (all channels):   GBP {k['cost_per_transaction']:.2f}")
    print(f"Online starts lost at identity check:  {k['identity_drop_share']:.1%}")
    warnings = 0
    if k["identity_drop_share"] > 0.05:
        print("WARN identity check loses >5% of online starts: test the fallback route")
        warnings += 1
    if len(argv) == 4:
        decided, overturned = int(argv[2]), int(argv[3])
        rate = overturned / decided
        print(f"Appeal overturn rate:                  {rate:.1%}")
        if rate > 0.20:
            print("WARN >20% of appealed decisions overturned: review the decision rules")
            warnings += 1
    return 1 if warnings else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv))
```

1. Save the first block as `service-quarter.csv` and the script as `service_kpis.py`.
2. Run `python3 service_kpis.py service-quarter.csv 300 84` (300 appeals decided, 84 overturned).
3. Simulate closing the phone line: delete the `phone` row, change the online row to `online,13000,9300,155000,1500` and
   the assisted row to `assisted_digital,900,800,50000,0` (of 1,150 phone completions, 300 move online, 150 to assisted
   digital and 700 give up), and run step 2 again without the appeal numbers.
4. Compare the two runs.

**Expected output** (checked by execution):

```text
Completed transactions (all channels): 12,000
Completion rate (digital):             73.1%
Digital take-up:                       80.4%
Cost per transaction (all channels):   GBP 35.00
Online starts lost at identity check:  11.2%
WARN identity check loses >5% of online starts: test the fallback route
Appeal overturn rate:                  28.0%
WARN >20% of appealed decisions overturned: review the decision rules
```

Exit code 1. Step 3: completed transactions 11,300, completion rate 72.7%, digital take-up 89.4%, cost per transaction
GBP 31.42, identity loss 11.5%, exit code 1. **The lesson:** with the phone line closed, take-up rises 9 points and unit cost
falls by about a tenth; the completion rate barely moves; 700 fewer people a quarter complete. Two headline KPIs improved
while the service got worse. Assisted digital help does not lower take-up, because it counts as digital. The 5% and 20%
thresholds are illustrative, not published standards. **Validation:** totals match your case-work counts. **Troubleshooting:**
`KeyError: 'online'` means no row is named `online`; `ValueError` usually means a blank cell. **Teardown:** delete the two files.

#### Lab 2 (intermediate): publish a dataset record an open-data portal can harvest

**Objective:** describe the service's performance data in **DCAT-US 3.0**, the US federal catalogue (`data.json`) profile, and
check its fields. **Prerequisites:** Python 3.8 or later; no account or cost. The publisher is an illustrative federal agency;
a city or a non-US body would use its own portal's profile, often based on W3C DCAT, "an RDF vocabulary designed to facilitate
interoperability between data catalogs published on the Web".[^dcat3]

As of October 2026, DCAT-US 3.0 is "the updated U.S. federal metadata standard required under OMB M-25-05", with migration
scripts from v1.1.[^dcatus3-updates] Data.gov still harvests v1.1 during the transition, but new implementations "should not be
built against" it; v1.1's `accessLevel` "is not part of the v3.0 core schema" (use `accessRights`).[^dcatus3] For a
dataset, `title`, `description`, `contactPoint` (with `fn` and a `mailto:` `hasEmail`) and `identifier` are Mandatory;
`keyword`, `modified`, `publisher`, `distribution` and `license` are among the Recommended fields.[^dcatus3-schema]

_Example status: JSON syntax-checked; script executed with Python 3.8.10 on 2026-10-23; the record is illustrative, was not
submitted to any portal, and was not run through the official validator._

```json
{
  "@type": "Catalog",
  "conformsTo": {"@type": "Standard", "title": "DCAT-US 3.0"},
  "dataset": [
    {
      "@type": "Dataset",
      "title": "Benefit renewal applications by channel, quarterly",
      "description": "Started and completed renewal applications by channel.",
      "keyword": ["benefits", "service performance"],
      "modified": "2026-10-01",
      "publisher": {"name": "Example Federal Agency"},
      "contactPoint": {
        "fn": "Service Performance Team",
        "hasEmail": "mailto:performance@example.gov"
      },
      "identifier": "https://data.example.gov/id/renewals-by-channel",
      "accessRights": "public",
      "license": "https://creativecommons.org/publicdomain/zero/1.0/",
      "distribution": [
        {
          "@type": "Distribution",
          "accessURL": "https://data.example.gov/renewals/by-channel.csv",
          "format": "CSV"
        }
      ]
    }
  ]
}
```

```python
"""Check a DCAT-US 3.0 catalog (data.json) against a subset of the schema.

Usage: python3 check_catalog.py data.json [--strict]
Mandatory fields fail; Recommended fields warn (fail with --strict).
A subset only: run the official validator before publishing.
"""
import json
import re
import sys

MANDATORY = ["title", "description", "contactPoint", "identifier"]
RECOMMENDED = ["keyword", "modified", "publisher", "distribution", "license"]
EMAIL = re.compile(r"^mailto:[^@\s]+@[\w.-]+\.\w+$")
DATE = re.compile(r"^\d{4}(-\d{2}(-\d{2}(T.+)?)?)?$")


def check(catalog, strict):
    fails, warns = [], []
    if not isinstance(catalog.get("dataset"), list):
        fails.append("catalog: dataset must be a list")
    seen = set()
    for i, d in enumerate(catalog.get("dataset") or []):
        tag = str(d.get("identifier") or f"dataset[{i}]")
        for f in MANDATORY:
            if d.get(f) in (None, "", [], {}):
                fails.append(f"{tag}: missing mandatory {f}")
        for f in RECOMMENDED:
            if d.get(f) in (None, "", [], {}):
                (fails if strict else warns).append(f"{tag}: missing {f}")
        contacts = d.get("contactPoint") or []
        for c in contacts if isinstance(contacts, list) else [contacts]:
            if not c.get("fn"):
                fails.append(f"{tag}: contactPoint needs fn")
            if not EMAIL.match(str(c.get("hasEmail", ""))):
                fails.append(f"{tag}: contactPoint.hasEmail must be mailto:")
        if d.get("modified") and not DATE.match(str(d["modified"])):
            fails.append(f"{tag}: modified must be YYYY, YYYY-MM or a date")
        if d.get("publisher") and not d["publisher"].get("name"):
            fails.append(f"{tag}: publisher needs name")
        if "accessLevel" in d and not d.get("accessRights"):
            warns.append(f"{tag}: v1.1 accessLevel without v3.0 accessRights")
        if tag in seen:
            fails.append(f"{tag}: duplicate identifier")
        seen.add(tag)
    return fails, warns


if __name__ == "__main__":
    with open(sys.argv[1]) as f:
        cat = json.load(f)
    fails, warns = check(cat, "--strict" in sys.argv)
    for p in fails:
        print("FAIL", p)
    for p in warns:
        print("WARN", p)
    n = len(cat.get("dataset") or [])
    print(f"{n} dataset(s): {len(fails)} failure(s), {len(warns)} warning(s)")
    sys.exit(1 if fails else 0)
```

1. Save the record as `data.json` and the script as `check_catalog.py`; run `python3 check_catalog.py data.json`.
2. Remove `mailto:` from `hasEmail` and run it again; then restore it.
3. Delete the `license` line and run it twice, without and with `--strict`.

**Expected output** (checked by execution). Step 1: `1 dataset(s): 0 failure(s), 0 warning(s)`, exit 0. Step 2:
`FAIL … contactPoint.hasEmail must be mailto:`, exit 1. Step 3: `WARN … missing license` with exit 0, then
`FAIL … missing license` with exit 1. **Validation:** before publishing a real federal catalogue, run the official DCAT-US 3.0
validator on harvest.data.gov;[^dcatus3-updates] this script checks only a subset of the schema. **Troubleshooting:**
`JSONDecodeError` is usually a trailing comma. **Teardown:** delete the files. In real use, `accessURL` must point at the
published CSV and be checked for broken links on a schedule.

#### Lab 3 (advanced): a public-value impact check before a change

**Objective:** decide whether a proposed change can go ahead, and on what conditions (a decision exercise, not code).
**Prerequisites:** a real proposal (for example "make renewals online-only"), the service record, and one person each from
policy and legal, operations, and data protection. About 90 minutes.

1. **Name the change and who it affects.** Write down which groups use the channel or decision being changed, with counts.
2. **Score each constraint** in the worksheet below: 0 = no effect, 1 = manageable with a named mitigation, 2 = serious
   without a redesign.
3. **For every 2, redesign or stop.** For every 1, name an owner, a mitigation and a measure.
4. **Record the decision** in the service record with a review date.

```text
PUBLIC-VALUE IMPACT CHECK                         service: ______________
Change: _______________________________________   date: ______________
Constraint            Question                                     Score
Mandate               Can affected people still get the outcome?   0 1 2
Universal access      Who cannot use the new route? Fallback?      0 1 2
Lawful decisions      Which rule changes? Legal source? Review?    0 1 2
Public money          New lock-in, contract change or cost shift?  0 1 2
Transparency          What will be published, and when?           0 1 2
Mitigations (owner, measure, review date): _______________________________
Decision: [ ] go  [ ] go with conditions  [ ] redesign  [ ] stop
Signed: service owner ________  legal ________  operations ________
```

**Expected output:** a signed worksheet. **Validation:** a colleague who was not in the room can tell from it why the decision
was made. **Troubleshooting:** if every score is 0, re-run step 1 with someone from the assisted channel present. **Teardown:** none; file the worksheet with the service record.
_Status: exercise design, not executed with a real team._

### Use cases and scenarios

Cases 1–4 are documented by auditors, regulators or official reviews; case 5 is a documented design choice; case 6 is
illustrative. Each "GovOps reading" is this page's interpretation.

#### Case 1: HealthCare.gov, launch and recovery

**Context.** HealthCare.gov served states without their own health insurance marketplace. At launch on 1 October 2013, users
"were met with website outages and technical malfunctions". **Findings.** The HHS OIG found the most critical problem was the
"absence of clear leadership, which caused delays in decisionmaking and a lack of clarity in project tasks", along with
"devoting too much time to developing policy, which left too little time for developing the website" and "failing to properly
manage its key website development contract". **Recovery.** A "badgeless" culture of CMS staff and contractors
working as one team, "ruthless prioritization", and a site recovered "for high consumer use within 2 months".[^oig-hcgov]
**GovOps reading.** A fixed public date makes the time left for testing the main risk. One owner, a peak load test and a
contract that leaves priorities with the government address each finding; "use agile" misses the leadership and contract
findings.

#### Case 2: unemployment insurance under a surge

**Context.** GAO studied eight states modernising their unemployment insurance IT systems; some states "had trouble processing
unemployment insurance claims due to issues with their IT systems". **Findings.** The legacy systems ranged "from 7 to about 50
years old"; states "reported improved system stability after migrating systems to cloud computing solutions" and named
challenges in "staffing, contracting, management, financial, and technical" areas.[^gao-ui] **GovOps reading.** Events and
policy set demand, so make the system elastic before the surge; strangler-style replacement keeps the old system paying people
while the new one grows.

#### Case 3: automated decisions that harmed people

**Robodebt (Australia).** Income was averaged over a year although very few recipients earn evenly, and the Commonwealth later
admitted its calculations "did not have a proper legal basis".[^whiteford] **Childcare benefits (Netherlands).** The Dutch DPA
fined the Tax Administration EUR 2.75 million in December 2021: it kept dual-nationality data it should have deleted in January
2014 and used nationality "as an indicator in a system that automatically designated certain applications as risky", although entitlement depends on lawful residence.[^ap-nl] **GovOps
reading.** In both cases the system kept running while complaints and adverse decisions accumulated. Signals surface earlier
with a legal source per rule, a necessity review per input, human review of adverse decisions, transparency records and a
reviewed overturn rate.

#### Case 4: a shared identity component that did not reach its targets

**Context.** GOV.UK Verify was a cross-government identity assurance platform. The 2016 business case expected "25 million
people would use Verify by 2020"; by February 2019, 3.6 million people had been verified, and "low take-up means that
government continues to fund it centrally".[^nao-verify] **GovOps reading.** A common component has two sets of users,
the services that adopt it and the people who must get through it: track both, and keep a fallback. The UK now offers GOV.UK One Login;[^onelogin] identity operations are on
[IdentityOps](../identityops/).

#### Case 5: continuity of the state

Estonia calls its data embassy "an extension in the cloud of the Estonian government": state-owned servers in Luxembourg under
a 2017 agreement, to "ensure digital continuity".[^estonia-embassy] **GovOps reading.** For a state, recovery can mean keeping
registers available when its own territory is not ([DisasterRecoveryOps](../disasterrecoveryops/)).

#### Case 6 (illustrative scenario): moving permits online

::: example Illustrative scenario: a city permit service
A city proposes closing its permit phone line (the Lab 1 numbers). Lab 3 scores universal access a 2. Decision: phone staff guide
callers through the online form where they can (assisted digital) and key in the case for those who cannot, so a non-digital
route stays; all-channel completions are published next to take-up.
:::

## Measure, govern and pay

### Metrics and KPIs

UK central government services "must also publish data on the mandatory key performance indicators":[^uk-p10] cost per
transaction, user satisfaction, completion rate and digital take-up, on data.gov.uk.[^uk-kpis] The access and legitimacy
loops need the additions marked "this page".

| KPI | Formula | Pitfall | Cadence |
|---|---|---|---|
| Completion rate | Completed digital ÷ digital started (incl. partial and failed); assisted digital counts as digital | A refusal still counts as complete | Monthly |
| Digital take-up | Completed digital (incl. assisted digital) ÷ completed in all channels | Rises when non-digital channels close (Lab 1) | Monthly (GOV.UK) |
| Cost per transaction | All-channel cost incl. staff, overheads, assisted support ÷ completed | Leaving out channels or overheads | Quarterly |
| User satisfaction | Overall percentage score from ratings | Usually asked at the end, so people who give up are missed | Monthly |
| All-channel completions (this page) | Completed transactions, all channels | Seasonal; compare like with like | Monthly |
| Exclusion signal (this page) | Starts lost at a named barrier ÷ online starts | Misses people who never start | Monthly |
| Appeal overturn rate (this page) | Decisions changed on review ÷ reviews decided | Not everyone who could appeal does | Quarterly |
| Time to decision (this page) | Median and 90th percentile days to decision | Averages hide the tail | Monthly |

**Worked calculation (the Lab 1 quarter).** Digital: online 12,500 started and 9,000 completed, assisted digital 700 and 650.
Non-digital: phone 1,150 and paper 1,200 completed. Cost GBP 420,000 in total. Completion rate = 9,650 ÷ 13,200 = **73.1%**.
Digital take-up = 9,650 ÷ 12,000 = **80.4%**. Cost per transaction = 420,000 ÷ 12,000 = **GBP 35.00**. Exclusion at identity =
1,400 ÷ 12,500 = **11.2%**. Overturn rate = 84 ÷ 300 = **28.0%**. Completion rate asks how many digital starts finish;
take-up asks what share of all completions were digital.

**Targets: what GOV.UK requires.** UK central government teams "must plan to continually increase digital take-up": initial
targets for take-up and assisted digital support in discovery, then a channel shift plan that "must" describe how and when
non-digital users move to the digital service, checked every six months or annually in live.[^uk-takeup] **This page's recommendation** (editorial, not GOV.UK guidance): set the target the
standard asks for, but pair it with two guardrails, all-channel completions and an exclusion signal, and never meet it by
closing a route people still need. People who never start are invisible to every funnel; only research and front-line staff see them.

::: figure Three feedback loops a government service has to run
```mermaid
flowchart TB
  SV["Live service"]:::core --> D1["Delivery loop:<br/>completion, cost, uptime"]:::neutral
  SV --> D2["Access loop:<br/>channel mix, exclusion,<br/>assisted outcomes"]:::decision
  SV --> D3["Legitimacy loop:<br/>appeals, overturns,<br/>complaints, audits"]:::risk
  D1 --> RV["Quarterly service review<br/>(owner, policy, ops)"]:::core
  D2 --> RV
  D3 --> RV
  RV --> CH["Changes: design,<br/>rules, channels, contracts"]:::core
  CH --> SV
  RV --> PB["Published data<br/>and records"]:::decision
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
```
Text equivalent: The live service feeds the delivery loop (completion, cost, uptime), the access loop (channel mix, exclusion,
assisted outcomes) and the legitimacy loop (appeals, overturns, complaints, audits). All three feed a quarterly service review
with the owner, policy and operations, which leads to changes in design, rules, channels and contracts, and to published data
and records.
:::

### Quality, security, privacy and compliance

- **Accessibility.** Under GOV.UK guidance, UK public sector bodies meet the legal requirements if they meet WCAG 2.2 AA
  (unless a valid legal reason, such as a disproportionate burden, applies) and publish an accessibility statement; GDS
  monitors, and the EHRC (Great Britain) and ECNI (Northern Ireland) enforce.[^uk-a11y] In EU Member States, public sector websites and apps
  need a statement and feedback mechanism, with national monitoring reported every three years.[^eu-wad] US federal agencies fall under Section 508;[^s508]
  state and local governments have ADA Title II duties and, from 2027, the rule's WCAG 2.1 AA standard.[^ada-guidance][^ada-ifr]
  Tools alone are not enough: GDS concluded that they "cannot be relied on, by themselves, to check the accessibility of a
  website".[^gds-a11y-tools] Test with disabled users.
- **Security.** Shared components and exchanges put many services behind one control: least privilege between agencies,
  logged register queries, an owner per integration.
- **Privacy.** People often cannot refuse to give data, which raises the bar for minimisation and retention (Case 3);
  programmes are on [PrivacyOps](../privacyops/).
- **Records and open code.** Records laws apply to documents, code and decisions; agree retention before retiring a system.
  GOV.UK asks teams to "Make all new source code open and reusable, and publish it under appropriate licences", with
  exceptions such as unannounced policy.[^uk-p12]

#### Security and data sovereignty

In government, national policy, not the team, decides how sensitive data is classified, where it may be hosted and how it
is protected. Examples (as of October 2026):

| Jurisdiction | Classification or categorisation | Hosting and data location | Security baseline |
|---|---|---|---|
| UK central government | Three tiers: OFFICIAL, SECRET, TOP SECRET; OFFICIAL is "The majority of information" in the public sector[^uk-gsc] | Public cloud first, "mandatory for central government"; overseas cloud allowed after due diligence; SECRET or TOP SECRET "unlikely to be suitable for Public Cloud"[^uk-cloud] | "Build to secure by design, in line with NCSC principles"[^uk-cloud] |
| US federal | FIPS 199: "three levels of potential impact" (low, moderate, high) for confidentiality, integrity and availability[^fips199] | M-24-15: "Agencies must obtain and maintain a FedRAMP authorization" for in-scope cloud services that hold federal information[^omb-m2415] | M-23-22: "Secure by design, secure by default"[^omb-m2322] |
| EU | Set nationally and by data protection law | Personal data: transfers outside the EU need a mechanism such as an adequacy decision or standard contractual clauses[^eu-transfers] | NIS2 covers "public administration at both central and regional levels"; transposition was due by 17 October 2024[^nis2] |

**This page's reading of the trade-off.** A sovereign or government-only cloud gives more control over location and access, but
usually fewer suppliers and managed services at a higher unit cost. A commodity public cloud is cheaper and more capable, but
brings exposure to foreign law and lock-in, which the contract and exit plan must handle. The UK policy chooses the second for
most data and asks teams to evidence any other choice.[^uk-cloud] Mechanics belong elsewhere: hosting and landing zones on [CloudOps](../cloudops/),
control evidence on [ComplianceOps](../complianceops/), recovery on [DisasterRecoveryOps](../disasterrecoveryops/).

### Cost, capacity and sustainability

- **Unit cost includes every channel and overhead,**[^uk-cpt] or channel shift looks cheaper than it is.
- **Capacity follows the calendar and the policy.** Deadlines and renewal windows are known; pandemic claims were not.[^gao-ui]
  Plan for known peaks and keep the ability to scale for unknown ones.
- **Legacy and lock-in are fiscal risks.** Price the risk of not modernising;[^gao-legacy] make exit real in contracts, as the
  playbook and the UK code ask. Buying itself is on [ProcurementOps](../procurementops/).
- **Sustainability** is a UK code point ("Make your technology sustainable");[^uk-tcop] methods are on [GreenOps](../greenops/).

### Assurance of the operating model

Watch between assessments: overdue accessibility issues, failed parity tests, rule changes without a legal source, contracts
near their end without a tested exit, and audit and ombudsman findings, which show what the internal loops missed.

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Phone queues grow after a release | A journey step broke for some users | Funnel by step; ask assisted staff | Roll back; staff up assisted channels | Parity test per release |
| Take-up rises with complaints | A channel closed or degraded | All-channel completions | Restore the route or a substitute | Impact check (Lab 3) |
| Many decisions overturned | Rule differs from law, or bad input | Trace overturned cases to rules | Pause adverse automation; re-run cases | Legal source per rule |
| Outage on a deadline day | Peak not planned; shared component failed | Monitoring; component status | Runbook below | Peak test; fallbacks |
| Small changes take months | Legacy system or contract terms | Map who can change what | Strangler slice; contract change | Exit plans; modular contracts |

### Worked runbook: the online service fails on deadline day

::: example Illustrative scenario: renewal deadline outage
Renewals close at midnight on 31 March. At 10:00 that day, after a change at the shared payments provider, about 40% of payment
attempts fail. 4,000 renewals are expected today. All numbers are invented.
:::

::: figure Deadline-day incident: restore the service, protect people's rights, then learn
```mermaid
flowchart TB
  D["Alert: payment failures<br/>on deadline day"]:::risk --> C["Incident lead opens<br/>incident; owner informed"]:::core
  C --> S{"Fix likely<br/>within 1 hour?"}:::decision
  S -- "yes" --> F["Fix or roll back;<br/>watch completions"]:::core
  S -- "no" --> P["Protect rights: owner and<br/>legal decide on extension"]:::decision
  P --> A["Assisted and offline routes<br/>take applications"]:::core
  P --> M["Public message:<br/>what to do, new date"]:::core
  F --> R["Reconcile payments<br/>and applications"]:::neutral
  A --> R
  M --> R
  R --> L["Review: published<br/>summary and actions"]:::neutral
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
```
Text equivalent: An alert shows payment failures on deadline day; the incident lead opens an incident and informs the owner.
If a fix is likely within one hour, the team fixes or rolls back and watches completions. If not, the owner and legal decide on
an extension; assisted and offline routes take applications, and a public message gives the new date. All paths end with
reconciling payments and applications, then a published review.
:::

1. **Detect (0–10 min).** Alert on payment failure rate, not only server errors.
2. **Command (10–20 min).** Name an incident lead; inform the owner ([IncidentOps](../incidentops/)).
3. **Decide on rights, not just uptime (by 11:00).** If no fix is likely within an hour, the owner and legal decide whether
   to extend the deadline or accept late applications, because people may otherwise lose an entitlement through no fault of
   their own.
4. **Open other routes.** Phone and counter staff take applications or record a timestamped intent to renew.
5. **Communicate** one plain message on the start page, in notifications and to front-line staff.
6. **Fix, then reconcile.** Match payments to applications, refund duplicates, contact people whose attempts failed.
7. **Publish a short review** and add the missing alert, fallback or supplier clause.

**Validation:** nobody who tried before midnight is penalised. **Rollback:** this page advises keeping an announced extension
even if the fix comes early.

### Anti-patterns and myths

- **"Digital by default" read as "digital only".** Closing non-digital channels improves take-up and excludes people (Lab 1).
- **The rules engine as a black box.** Rules nobody can trace to the law; keep a legal source per rule and publish rules where
  possible.[^ag-adm]
- **"It is in the cloud, so it will scale."** Shared components, legacy back ends and staff still cap throughput.
- **Compliance by statement.** "Fully compliant" without testing; publish known issues with dates instead.
- **Myth: "Government is just slow."** The cases here failed for specific, fixable reasons.

## Deciding and adopting

### When to use and when not to use

**Use it** when a public body, or a contractor on its behalf, runs a service that people must use, that decides
entitlements, obligations or permissions, or that public money pays for.

**Use less of it** for an informational website ([WebOps](../webops/), [ContentOps](../contentops/)) or an internal tool with
no decisions about the public. A government-owned company in a competitive market may be closer to a commercial service.
**Do not expect it to fix bad law:** operations can show the evidence, but the remedy is a policy change.

### Decision framework

A frequent GovOps decision is whether to reuse a shared component, buy, or build. The tree is this page's proposal.

::: figure Reuse, buy or build a capability for a public service
```mermaid
flowchart TB
  Q1{"Is there a shared<br/>government component?"}:::decision
  Q1 -- "yes" --> Q2{"Does it meet the need,<br/>including the fallback?"}:::decision
  Q2 -- "yes" --> R["Reuse it; add your<br/>own fallback route"]:::core
  Q2 -- "no" --> CO["Contribute the missing<br/>part, or ask its owner"]:::neutral
  Q1 -- "no" --> Q3{"Is it a commodity<br/>(email, payments)?"}:::decision
  Q3 -- "yes" --> B["Buy, with open standards<br/>and a tested exit"]:::core
  Q3 -- "no" --> Q4{"Does it encode law<br/>or public decisions?"}:::decision
  Q4 -- "yes" --> BL["Build or control it;<br/>open code where possible"]:::core
  Q4 -- "no" --> B
  CO --> Q3
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
```
Text equivalent: If a shared government component exists and meets the need, reuse it and add your own fallback route; if it
falls short, contribute or ask its owner, then continue as if it did not exist. A commodity such as email or payments is
bought with open standards and a tested exit. A capability that encodes law or public decisions is built or controlled, with
open code where possible; anything else is bought.
:::

**Assumptions.** Rules that decide entitlements must track the law, so they stay under government control; commodities are
cheaper to buy if exit is real; shared components concentrate risk, so every service keeps a fallback.

### Maturity model

This is **this Atlas's model**, not an official one. Each level has an exit criterion you can check.

| Level | Observable behaviour | Exit criterion |
|---|---|---|
| 1. Running | The service works; ownership is unclear; KPIs cover the website only | A named owner and a service record exist |
| 2. Measured | All-channel KPIs published; accessibility statement maintained | Four quarters of published, reconciled data |
| 3. Accountable | Every decision rule has a legal source; appeals and overturns reviewed; transparency records published | Overturn rate reviewed each quarter with actions |
| 4. Resilient | Peak load tested; fallback for each shared component; exit plans tested | A deadline day passed with no person losing a right because of the service |
| 5. Adaptive | Rule changes reach production in days with legal sign-off; legacy reduced slice by slice | A policy change shipped on time, with no rise in overturns |

### Adoption roadmap: 30/60/90 days

| Days | Actions | Milestone |
|---|---|---|
| 1–30 | Name the owner; write the service record; list channels, rules and contracts; set up all-channel counts | Service record reviewed by policy, legal and operations |
| 31–60 | Publish the KPIs; run the assisted-route parity test; inventory automated decisions and their legal sources; check the accessibility statement | First published data; decision inventory with owners |
| 61–90 | Load-test the next peak; write exit plans for contracts ending within two years; start overturn-rate reviews; run Lab 3 on the next planned change | Peak test passed; first quarterly service review held |

**Quick win:** count completed transactions across all channels.

## Toolkit

### Checklists

**Launch readiness**

- [ ] Named service owner and a current service record
- [ ] Assisted route completes the same transaction (parity test passed)
- [ ] Accessibility tested with assistive technology; statement published with known issues
- [ ] KPIs collected for every channel; publication date set
- [ ] Every automated rule traced to a legal source; adverse-decision review in place
- [ ] Load test at the expected deadline peak; fallback for each shared component
- [ ] Incident roles named, including who decides on deadline extensions

**Automated-decision preflight**

- [ ] Legal basis for automating this decision confirmed in writing
- [ ] Each input is necessary and lawful for the purpose (no proxies such as nationality without a legal basis)
- [ ] Review route explained in the decision notice
- [ ] Transparency record drafted; business rules ready for independent scrutiny
- [ ] Overturn rate and complaints by group monitored from day one

**Contract and exit**

- [ ] Data export tested and restored in the last 12 months
- [ ] Open standards for data and interfaces
- [ ] Renewal date in the service record, with a decision 12 months before

**Retirement**

- [ ] Remaining users moved; records retained under the schedule; public notice given; access removed

### Templates

**One-page service charter**

```text
SERVICE CHARTER                                  version / date: ________
Service: ____________________   Owner (accountable): ____________________
Who must or may use it (by law/policy): __________________________________
Outcome for the person: __________________________________________________
Channels and the assisted route: _________________________________________
Decisions made, legal basis, review route: _______________________________
Published: KPIs [ ] accessibility statement [ ] transparency records [ ]
Peaks and deadlines: _____________________________________________________
Shared components and fallbacks: _________________________________________
Contracts ending within 24 months, exit plan status: ______________________
Next service review: __________   Next assessment or audit: ______________
```

**Minimal transparency record for an algorithmic tool** (adapt to your national standard, for example the UK ATRS[^uk-atrs])

```text
TOOL: ____________________   SERVICE: ____________________   OWNER: _________
What it does, in plain language: _____________________________________________
Decision it supports, and who makes the final decision: ______________________
Legal basis: _____________   Inputs used: _____________   Inputs excluded: ____
How a person can ask for review: _____________________________________________
Testing done (accuracy, bias by group): ____________   Date: _____________
Monitoring: overturn rate, complaints, drift   Review date: _______________
```

### Deep comparisons

| Dimension | Commercial service operations | Government service operations (this page) |
|---|---|---|
| Feedback when it fails | Churn, revenue, reviews | Built on purpose: completion by channel, complaints, appeals, audits |
| Openness | Confidential by default | Publication by default in many jurisdictions; FOI applies |
| Peaks | Campaigns, seasons | Statutory deadlines, policy changes, emergencies |
| Retirement | When unprofitable | Only when everyone has an alternative and records are kept |

The other differences (users, decisions, money) are the [public-value constraints](#the-problem-govops-solves).

### FAQ

**Is GovOps a recognised discipline?** No. It names state agencies in California and Utah and a federal shared-services
marketplace; this page's reading is an editorial choice.

**Does a local council need all of this?** Start with the service record, all-channel counts and an assisted route.

**Is closing the phone line ever right?** Sometimes, if other routes, including assisted digital help, reach everyone the
service is for. Run the impact check and watch all-channel completions and complaints.

**We use a vendor's platform. Who is accountable?** The public body. The contract should give it the data, the logs, the right
to change rules quickly and a tested exit.

**Is AI allowed in decisions about people?** It depends on the jurisdiction; where allowed, the obligations in
[automation and AI](#automation-and-ai) apply in full.

## Going further

### Advanced topics and emerging direction

- **Rules as code (active practice and research).** Drafting rules in legislation, regulation and policy "in
  machine-consumable languages (code) so they can be read and used by computers".[^rac] This page's caution: rules that need
  judgement do not translate cleanly, and a coded rule still needs a legal owner.
- **DPI safeguards (policy direction).** Countries building identity, payments and data exchange as shared infrastructure
  face the concentration risk described above; the G20 declaration links interoperable DPI to cross-border data flows "while
  respecting applicable legal frameworks".[^g20-delhi]
- **AI transparency (established in the UK).** Algorithm records are mandatory for UK government departments.[^uk-atrs]
- **Changes in institutions (watch).** Central digital teams are created, renamed and closed, as the US changes of 2025 show
  (see [origins](#origins-and-evolution)). Write your operating model so that it does not depend on any one central team.

### Learning path

| Stage | What to do |
|---|---|
| Prerequisites | Basic service design; how your jurisdiction makes and reviews administrative decisions |
| 1-day primer | Read the GOV.UK Service Standard[^uk-std] and the US playbook;[^usds-playbook] read this page's use cases |
| 1-week practice | Write the service record for a real service; run Lab 1 on its data |
| 30 days | Run Lab 3 on a planned change; run an assisted-route parity test; publish one dataset (Lab 2) |
| Specialise | Accessibility, automated decisions ([DecisionOps](../decisionops/)), identity ([IdentityOps](../identityops/)), procurement ([ProcurementOps](../procurementops/)) |
| Portfolio ideas | A published performance dashboard; a decision inventory with legal sources; an exit plan with a tested export |

## Wrap-up

### Executive recap and cheat sheet

- **Decide:** who owns each service; which decisions are automated, on what legal basis; which shared components to use,
  with what fallback.
- **Practise and publish:** parity tests, rule change control, deadline readiness, exit plans; KPIs, statements, records.
- **Measure:** the GOV.UK KPIs across all channels, plus exclusion, overturn rate and time to decision.
- **Watch:** channel closures that improve KPIs; rules without a legal source; untested exits; deadline days.
- **Next action:** write the service record for your most-used service this month.

### A judgement call: close the paper form or keep it?

**Situation (illustrative).** A benefit renewal is 92% online and 8% paper (about 40,000 people a year, many older or with
poor connectivity). Paper costs four times as much per renewal. Finance proposes withdrawing it to fund the online route.

**Option A:** withdraw paper and invest online. **Option B:** keep paper but cut its cost (redesign, pre-fill from records).

**Assumptions to test.** How many of the 40,000 could renew online with help? Is there a legal duty to offer a non-digital
route? Someone who misses a renewal may lose payments.

**Why A is attractive and can be wrong.** Take-up and unit cost improve, which the published KPIs reward. If even a small
share cannot renew, the service fails those with most to lose, and cost moves to complaints, appeals and other services.

**A defensible decision.** B now, with conditions: run the impact check; pilot assisted online renewal with paper users;
measure completed renewals across all routes for a year; revisit withdrawal only if former paper users' completions hold.
**Uncertainty:** the pilot may show that A is right. The evidence decides, not the KPI.

### Learning objectives and mastery check

After this page you can explain the official meanings of GovOps and this page's reading; calculate the GOV.UK KPIs across
channels and explain their traps; design assisted-route and automated-decision safeguards; run a deadline-day incident; and
decide reuse, buy or build.

1. Digital take-up rose from 80% to 89% after the phone line closed. Is the service better?

::: answer Is the service better?
Not necessarily. In Lab 1 the same change cut all-channel completions by 700 a quarter; take-up rose because the denominator
lost a non-digital channel.
:::

2. Which three GOV.UK mandatory KPIs can be computed from counts and cost? Give one formula.

::: answer GOV.UK KPIs
Completion rate, digital take-up and cost per transaction (all-channel cost, including overheads, ÷ completed transactions).
:::

3. 28% of appealed decisions are overturned. What do you do first?

::: answer High overturn rate
Sample overturned cases and trace each to the rule and input that produced it. If a rule differs from the law, pause the
automated adverse path, correct it and re-check all affected cases, not only those appealed.
:::

4. A shared identity component fails for 10% of applicants. What should every service using it have?

::: answer Shared component failure
A fallback that reaches the same outcome, a proofing-completion metric and a support route to the component owner.
:::

5. On deadline day, payments fail and no fix is likely within an hour. Which decision makes it a government incident?

::: answer Deadline day
Whether to extend the deadline or accept late applications so nobody loses a right because the service failed, decided by the
owner with legal advice and communicated in every channel.
:::

6. What should a public body build or control rather than buy, and why?

::: answer Build or control
Rules that encode law or public decisions, because they must be traceable to the law, change when it changes, and be open to
scrutiny. Commodities can be bought with open standards and a tested exit.
:::

### Conclusion

"GovOps" names agencies, not a discipline. The practice it stands for here is real and hard: running services that everyone
may need, that make decisions people can challenge, that spend public money and that work in public. The engineering is
shared with every other Ops page. What changes is that the market will not tell you when you fail, so you build the signals
yourself: count every channel, watch who drops out, read your appeals, publish your numbers and keep a way out of every
contract. The cases on this page failed because nobody owned the whole service, because rules drifted from the law, or because
the people who struggled were not counted. Each of those is an operating choice, so each can be fixed.

## Sources and further reading

All sources were opened on 2026-10-23. Legal statements are dated, limited to the jurisdictions named, and not legal advice.

[^ca-about]: [About us](https://www.govops.ca.gov/about) — California Government Operations Agency (GovOps), undated. Checked 2026-10-23.
[^ca-depts]: [Our Departments, Boards and Programs](https://www.govops.ca.gov/who-we-are/departments/) — California Government Operations Agency, undated (list as shown). Checked 2026-10-23.
[^utah-about]: [About](https://govops.utah.gov/about) — Utah Department of Government Operations, undated. Checked 2026-10-23.
[^gsa-mkt]: [GovOps Marketplace: Enterprise Shared Services](https://ussm.gsa.gov/marketplace/) — US GSA, undated. Checked 2026-10-23.
[^uk-std]: [Service Standard](https://www.gov.uk/service-manual/service-standard) — GOV.UK Service Manual, undated. Checked 2026-10-23.
[^uk-scope]: [Check if you need to meet the Service Standard or get an assessment](https://www.gov.uk/service-manual/digital-by-default/scope-of-the-standard) — GOV.UK Service Manual, published 2019-05-08, updated 2024-09-03. Checked 2026-10-23.
[^uk-p5]: [Make sure everyone can use the service (point 5)](https://www.gov.uk/service-manual/service-standard/point-5-make-sure-everyone-can-use-the-service) — GOV.UK Service Manual, updated 2022-05-30. Checked 2026-10-23.
[^uk-p10]: [Define what success looks like and publish performance data (point 10)](https://www.gov.uk/service-manual/service-standard/point-10-define-success-publish-performance-data) — GOV.UK Service Manual, updated 2022-05-30. Checked 2026-10-23.
[^uk-p12]: [Make new source code open (point 12)](https://www.gov.uk/service-manual/service-standard/point-12-make-new-source-code-open) — GOV.UK Service Manual, updated 2022-05-30. Checked 2026-10-23.
[^uk-phases]: [Agile delivery](https://www.gov.uk/service-manual/agile-delivery) — GOV.UK Service Manual, undated. Checked 2026-10-23.
[^uk-kpis]: [Data you must publish](https://www.gov.uk/service-manual/measuring-success/data-you-must-publish) — GOV.UK Service Manual, updated 2021-04-06. Checked 2026-10-23.
[^uk-completion]: [Measuring completion rate](https://www.gov.uk/service-manual/measuring-success/measuring-completion-rate) — GOV.UK Service Manual, updated 2021-02-19. Checked 2026-10-23.
[^uk-takeup]: [Measuring digital take-up](https://www.gov.uk/service-manual/measuring-success/measuring-digital-take-up) — GOV.UK Service Manual, updated 2021-02-19. Checked 2026-10-23.
[^uk-cpt]: [Measuring cost per transaction](https://www.gov.uk/service-manual/measuring-success/measuring-cost-per-transaction) — GOV.UK Service Manual, updated 2021-02-19. Checked 2026-10-23.
[^uk-tcop]: [The Technology Code of Practice](https://www.gov.uk/guidance/the-technology-code-of-practice) — GOV.UK, updated 2025-07-07. Checked 2026-10-23.
[^uk-a11y]: [Understanding accessibility requirements for public sector bodies](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) — GOV.UK, updated 2024-09-30. Checked 2026-10-23.
[^uk-atrs]: [Algorithmic Transparency Recording Standard Hub](https://www.gov.uk/government/collections/algorithmic-transparency-recording-standard-hub) — GOV.UK, updated 2025-05-08. Checked 2026-10-23.
[^uk-procurement]: [How to use the Central Digital Platform](https://www.gov.uk/government/publications/procurement-act-2023-short-guides/buyers-and-suppliers-how-to-use-the-central-digital-platform-the-enhanced-find-a-tender-service-html) — GOV.UK, updated 2026-10-21. Checked 2026-10-23.
[^gds-a11y-tools]: [What we found when we tested tools on the world's least-accessible webpage](https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/) — Mehmet Duran, GDS Accessibility blog, 2017-02-24. Checked 2026-10-23.
[^notify]: [GOV.UK Notify](https://www.notifications.service.gov.uk/) — Government Digital Service, live counts. Checked 2026-10-23.
[^pay]: [GOV.UK Pay](https://www.payments.service.gov.uk/) — Government Digital Service, live figures. Checked 2026-10-23.
[^onelogin]: [GOV.UK One Login](https://www.sign-in.service.gov.uk/) — Government Digital Service, undated. Checked 2026-10-23.
[^nao-verify]: [Investigation into Verify](https://www.nao.org.uk/reports/investigation-into-verify/) — UK National Audit Office, 2019-03-05. Checked 2026-10-23.
[^eo14338]: [Executive Order 14338: Improving Our Nation Through Better Design](https://www.presidency.ucsb.edu/documents/executive-order-14338-improving-our-nation-through-better-design) — The American Presidency Project, order dated 2025-08-21. Checked 2026-10-23.
[^usds-playbook]: [The Digital Services Playbook](https://playbook.usds.gov/) — US Digital Service (now titled US DOGE Service), undated. Checked 2026-10-23.
[^eo14158]: [Executive Order 14158: Establishing and Implementing the President's "Department of Government Efficiency"](https://www.presidency.ucsb.edu/documents/executive-order-14158-establishing-and-implementing-the-presidents-department-government) — The American Presidency Project, order dated 2025-01-20. Checked 2026-10-23.
[^nextgov-18f]: [GSA eliminates 18F](https://www.nextgov.com/people/2025/03/gsa-eliminates-18f/403400/) — Nextgov/FCW, 2025-03-01. Checked 2026-10-23.
[^omb-m2322]: [Requirements for delivering a digital-first public experience](https://digital.gov/resources/delivering-digital-first-public-experience) — Digital.gov (GSA), on OMB M-23-22 of September 2023. Checked 2026-10-23.
[^s508]: [IT Accessibility Laws and Policies](https://www.section508.gov/manage/laws-and-policies/) — Section508.gov (GSA), reviewed October 2026. Checked 2026-10-23.
[^ada-guidance]: [Guidance on Web Accessibility and the ADA](https://www.ada.gov/resources/web-guidance/) — US Department of Justice, 2022-03-18 (banner notes the 2024 rule). Checked 2026-10-23.
[^ada-ifr]: [Extension of Compliance Dates: Accessibility of Web Information and Services of State and Local Government Entities (interim final rule)](https://www.ada.gov/assets/pdfs/2026-ifr.pdf) — US Department of Justice, effective 2026-04-20. Checked 2026-10-23.
[^uswds]: [U.S. Web Design System](https://designsystem.digital.gov/) — GSA, v3.14.0 shown. Checked 2026-10-23.
[^logingov]: [About us](https://login.gov/about-us/) — Login.gov, GSA Technology Transformation Services, undated. Checked 2026-10-23.
[^fedramp]: [FedRAMP](https://www.gsa.gov/technology/government-it-initiatives/fedramp) — GSA, updated 2026-03-04. Checked 2026-10-23.
[^dcatus3]: [DCAT-US Schema v3.0](https://resources.data.gov/resources/dcat-us3/) — resources.data.gov (Data.gov, GSA), page changelog to September 2026. Checked 2026-10-23.
[^dcatus3-updates]: [DCAT-US 3 Schedule, Maintenance, and Release Plan](https://resources.data.gov/resources/dcat-us-3-updates/) — resources.data.gov, updated 2026-07-07. Checked 2026-10-23.
[^dcatus3-schema]: [DCAT-US 3.0 JSON Schema: Dataset definition](https://github.com/GSA/dcat-us/blob/main/jsonschema/definitions/Dataset.json) — GSA, GitHub (main branch), requirement levels per field. Checked 2026-10-23.
[^uk-gsc]: [Government Security Classifications Policy: quick read](https://www.gov.uk/government/publications/government-security-classifications/government-security-classifications-policy-quick-read-html) — Cabinet Office, GOV.UK, version 2.0 of 2024-08-05. Checked 2026-10-23.
[^uk-cloud]: [Government Cloud First policy](https://www.gov.uk/guidance/government-cloud-first-policy) — GOV.UK, updated 2023-06-19. Checked 2026-10-23.
[^omb-m2415]: [M-24-15: Modernizing the Federal Risk and Authorization Management Program (FedRAMP)](https://www.whitehouse.gov/wp-content/uploads/2024/07/M-24-15-Modernizing-the-Federal-Risk-and-Authorization-Management-Program.pdf) — US Office of Management and Budget, 2024-07-25, section III (PDF read). Checked 2026-10-23.
[^fips199]: [FIPS 199: Standards for Security Categorization of Federal Information and Information Systems](https://csrc.nist.gov/pubs/fips/199/final) — NIST, February 2004 (PDF read). Checked 2026-10-23.
[^nis2]: [NIS2 Directive: new rules on cybersecurity of network and information systems](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) — European Commission, updated 2026-07-02. Checked 2026-10-23.
[^eu-transfers]: [Rules on international data transfers](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/rules-international-data-transfers_en) — European Commission, undated. Checked 2026-10-23.
[^oig-hcgov]: [HealthCare.gov: Case Study of CMS Management of the Federal Marketplace (OEI-06-14-00350)](https://oig.hhs.gov/reports/all/2016/healthcaregov-case-study-of-cms-management-of-the-federal-marketplace) — HHS Office of Inspector General, 2016-02-22. Checked 2026-10-23.
[^gao-ui]: [Unemployment Insurance: DOL Needs to Further Help States Overcome IT Modernization Challenges (GAO-23-105478)](https://www.gao.gov/products/gao-23-105478) — US GAO, published 2023-07-10. Checked 2026-10-23.
[^gao-legacy]: [Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795)](https://www.gao.gov/products/gao-25-107795) — US GAO, 2025-07-17. Checked 2026-10-23.
[^eu-wad]: [Web accessibility](https://digital-strategy.ec.europa.eu/en/policies/web-accessibility) — European Commission, updated 2026-06-23. Checked 2026-10-23.
[^interop-act]: [Interoperable Europe Act](https://interoperable-europe.ec.europa.eu/interoperable-europe/interoperable-europe-act) — Interoperable Europe Portal, European Commission, undated. Checked 2026-10-23.
[^rac]: [Rules as Code: OPSI and COHUBICOL](https://interoperable-europe.ec.europa.eu/collection/digital-ready-policymaking/news/rules-code-opsi-cohubicol) — Interoperable Europe Portal, 2021-05-12 (quoting de Sousa, 2019). Checked 2026-10-23.
[^ap-nl]: [Tax Administration fined for discriminatory and unlawful data processing](https://www.autoriteitpersoonsgegevens.nl/en/current/tax-administration-fined-for-discriminatory-and-unlawful-data-processing) — Autoriteit Persoonsgegevens (Dutch DPA), 2021-12-07. Checked 2026-10-23.
[^robodebt-rc]: [Report of the Royal Commission into the Robodebt Scheme](https://robodebt.royalcommission.gov.au/publications/report) — Commonwealth of Australia, 2023; recommendation 17.1 in Volume 2, chapter 17 (read via the Internet Archive snapshot of 2024-12-31). Checked 2026-10-23.
[^ag-adm]: [Use of automated decision-making by government: consultation paper](https://consultations.ag.gov.au/integrity/adm/user_uploads/consultation-paper-use-of-automated-decision-making-by-government.pdf) — Attorney-General's Department, Australia, November 2024. Checked 2026-10-23.
[^whiteford]: [The Robodebt royal commission will tell us who's to blame, but that's just the start](https://theconversation.com/the-robodebt-royal-commission-will-tell-us-whos-to-blame-but-thats-just-the-start-208916) — Peter Whiteford, The Conversation, 2023-07-06. Checked 2026-10-23.
[^g20-delhi]: [G20 New Delhi Leaders' Declaration](https://www.g20.in/content/dam/gtwenty/gtwenty_new/document/G20-New-Delhi-Leaders-Declaration.pdf) — G20, New Delhi, 9–10 September 2023, paragraph 55 (read via the Internet Archive; inner pages are headed "Zero Draft"). Checked 2026-10-23.
[^xroad]: [X-Road](https://x-road.global/) — Nordic Institute for Interoperability Solutions, undated. Checked 2026-10-23.
[^estonia-embassy]: [Data embassy](https://e-estonia.com/solutions/e-governance/data-embassy/) — e-Estonia, undated. Checked 2026-10-23.
[^odc]: [Principles](https://opendatacharter.org/principles/) — International Open Data Charter, developed 2015. Checked 2026-10-23.
[^dcat3]: [Data Catalog Vocabulary (DCAT) Version 3](https://www.w3.org/TR/vocab-dcat-3/) — W3C Recommendation, 2024-08-22. Checked 2026-10-23.
[^fowler]: [Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) — Martin Fowler, dated 2024-08-22. Checked 2026-10-23.

**Changelog.** 2026-10-23: first version (research, ledger, draft, labs executed, diagrams); no independent review yet.
2026-10-23 (r1 revision): Lab 1 follows GOV.UK on assisted digital; take-up targets stated; ADA framing fixed; Lab 2 on
DCAT-US 3.0; security and data sovereignty added; primary sources for Robodebt and G20 DPI; trims.
2026-10-23, post-score polish: US FedRAMP row now cites OMB M-24-15; GDS tool test credits Tenon (37%) and Asqatasun (41%);
EU accessibility scoped to Member States' public sector; EU transfer rule moved to the hosting column; G20 "Zero Draft" label noted.