GovOps

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),^[1] whose 15 departments and programmes include the Department of Technology and CalHR (as listed on 2026-10-23);^[2] of Utah’s Department of Government Operations, formed in 2021 from three departments;^[3] and of the GovOps Marketplace, a GSA catalogue of shared services for federal agencies.^[4]

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.

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.

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.”^[5] 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”.^[6]
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”.^[7] The use cases examine each.

• 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, SRE and 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; 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.

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

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”.^[8] “If you’re developing a transactional service for central government, you must get it assessed.”^[9]
• Playbooks. The US Digital Services Playbook has 13 plays, including “Structure budgets and contracts to support delivery” and “Default to open”.^[10] Its institutions changed in 2025: Executive Order 14158 renamed the US Digital Service the “United States DOGE Service”,^[11] and GSA eliminated its 18F consultancy (about 90 staff) as “non-critical”.^[12] In August 2025, Executive Order 14338 created a National Design Studio with a Chief Design Officer in the Executive Office of the President.^[13] 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”.^[14]
• 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).

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.

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.

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

A service standard to be assessed against (the GOV.UK 14 points,^[8] or the US federal requirements in OMB memo M-23-22^[16]); a service record per service (see the 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”^[17]); published performance data; transparency records (accessibility statement, algorithm records, open code and data); and independent assurance (assessments, auditors, ombudsmen).

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

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”,^[10] and Case 1 shows the cost of not having one.

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

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,^[19] and assessment can be a condition of that approval.^[9]
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.^[9]
3. Publication (continuous). Published data invites scrutiny between assessments (see metrics).
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.

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

• 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),^[20] and GOV.UK Pay reports “70,000+ payments processed every day”.^[21] 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.^[22] 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”.^[23]
• Trust boundaries (the labelled edges). Each crossing to another provider or agency needs an owner, an agreement and logging; design details are on IdentityOps and IntegrationOps.

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

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.
• 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.^[7]
• Challenge. Review outcomes are data. A high overturn rate means the original decisions are wrong.

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”.^[24] 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.

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

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

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”.^[40] 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”.^[41]
• 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”.^[5]
• Transparency records. The UK ATRS “establishes a standardised way for public sector organisations to publish information” about algorithmic tools.^[26]
• 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).

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.

# 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.

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”;^[42] digital take-up divides them by “the total number of transactions from all channels in the same period”.^[15] Both count assisted digital transactions as digital. Cost per transaction divides the cost “through all channels” by completed transactions.^[43] 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,^[44] 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.

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

"""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):

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.

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”.^[36]

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.^[45] 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).^[37] 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.^[46]

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.

{
  "@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"
        }
      ]
    }
  ]
}

"""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;^[45] 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.

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.

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.

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.

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”.^[47] 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.

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.^[48] 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.

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”.^[40] 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.^[5] 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.

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”.^[49] 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;^[34] identity operations are on IdentityOps.

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”.^[50] GovOps reading. For a state, recovery can mean keeping registers available when its own territory is not (DisasterRecoveryOps).

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

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.^[15] 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.

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

• 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.^[25] In EU Member States, public sector websites and apps need a statement and feedback mechanism, with national monitoring reported every three years.^[31] US federal agencies fall under Section 508;^[28] state and local governments have ADA Title II duties and, from 2027, the rule’s WCAG 2.1 AA standard.^[29][30] Tools alone are not enough: GDS concluded that they “cannot be relied on, by themselves, to check the accessibility of a website”.^[39] 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.
• 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.^[52]

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):

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.^[54] Mechanics belong elsewhere: hosting and landing zones on CloudOps, control evidence on ComplianceOps, recovery on DisasterRecoveryOps.

• Unit cost includes every channel and overhead,^[43] 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.^[48] 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;^[23] make exit real in contracts, as the playbook and the UK code ask. Buying itself is on ProcurementOps.
• Sustainability is a UK code point (“Make your technology sustainable”);^[19] methods are on GreenOps.

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.

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

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).
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.

• “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.^[7]
• “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.

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, 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.

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

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

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.

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

Quick win: count completed transactions across all channels.

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

One-page service charter

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^[26])

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: _______________

The other differences (users, decisions, money) are the public-value constraints.

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 apply in full.

• 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”.^[59] 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”.^[14]
• AI transparency (established in the UK). Algorithm records are mandatory for UK government departments.^[26]
• Changes in institutions (watch). Central digital teams are created, renamed and closed, as the US changes of 2025 show (see origins). Write your operating model so that it does not depend on any one central team.

• 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.

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.

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?

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

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

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

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

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

“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.

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

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.