A person standing at a public-service counter may never know which company built the system behind it. That is usually as it should be. The trouble begins when a disputed balance, a failed identity match or a missing record becomes an official fact, while the authority responsible for the decision cannot fully explain how the result was produced.
This is the boundary between buying software and delegating public power. Private vendors can bring specialist engineering, mature security operations and the capacity to keep complicated services running. But when software mediates identity, benefits, tax, justice or other rights-critical functions, the public authority must retain more than ownership of a contract. It must preserve the practical ability to understand, audit, operate and change the system, including the ability to replace a supplier without losing the service, its evidence or its institutional memory.
The human stakes are documented. The UK Post Office Horizon IT Inquiry has examined how apparent accounting shortfalls were handled, how bugs and discrepancies were investigated, and how system evidence entered legal and disciplinary processes. Its first final-report volume, published in July 2025, focuses on the human impact and redress; further final findings on technical and governance questions were still pending at the time of writing. It is therefore too early to treat the inquiry as a completed technical verdict. What is already clear from the official record is that software outputs can become consequential claims about people, and that institutional capacity to question those outputs matters. The inquiry’s published reports and statements are a reminder that accountability cannot be passed down a supply chain.
When a system becomes infrastructure
A routine software purchase can often be judged by familiar criteria: whether the product has the required features, meets security requirements, stays within budget and satisfies its service-level agreement. A rights-critical digital service has a different shape. It may authenticate a person, retrieve attributes from authoritative registers, apply rules, route a case, record a decision, issue a notice and preserve evidence for review. Failure does not merely inconvenience a user. It can change whether that person is recognised, paid, permitted, investigated or heard.
The distinction is not whether a system runs in a government data centre or a commercial cloud. Nor is it whether the code is public or proprietary. The decisive question is what happens when its output acquires administrative force. If a system helps determine a person’s legal position, the authority needs what might be called operational sovereignty: enough knowledge, access, skill and contractual freedom to discharge its own public duties under normal conditions and during failure.
That does not require every public body to manufacture every component. Governments have always depended on outside expertise. It does require them to know where authority resides in the technical design. An identity service says who has authenticated. A source register supplies an address, licence or family relationship. A rules service interprets relevant policy. A case-management system coordinates human work. An event broker carries changes between systems. Logging and monitoring show what was accessed, changed and decided. The notice and appeal journey turns a machine-mediated event into something a person can understand and contest.
These layers should not collapse into one opaque product. A wrong record and a correctly applied rule are different problems. So are a failed login, a stale data feed and an unlawful decision policy. When they are indistinguishable to the authority, a vendor support ticket becomes the only route to explanation. That is not merely inconvenient procurement. It is a weakness in public accountability.
Modularity has to survive contact with reality
Modularity is often offered as the answer: divide a large system into replaceable components and let several suppliers compete. The idea is sound, but boxes on an architecture diagram do not create replaceability. A boundary works only when both sides share precise meanings, documented interfaces, versioning rules, security expectations and tests that another implementation can pass.
Suppose an eligibility service asks a population register whether a person is ordinarily resident. A technically open interface is not enough if one supplier encodes temporary absence as an empty field and another interprets an empty field as “not resident”. The syntax can interoperate while the decision fails. Legal, organisational, semantic and technical interoperability have to meet at the same boundary. This broader conception sits behind the EU’s Interoperable Europe Act, adopted in 2024 to strengthen cross-border interoperability among public administrations.
Open standards can reduce dependence on a single implementation. The UK government’s Open Standards Principles explicitly connect standards with avoiding unintentional lock-in, enabling multiple suppliers and breaking large contracts into components. Yet standards can be nominal. An interface may be documented but incomplete, burdened by proprietary extensions or impossible to use without an undocumented orchestration layer. Conformance tests, representative test data and independent implementations are what turn a standard from a promise into a working exit route.
Open source addresses a different part of the problem. It can permit inspection, reuse and continuity when a supplier leaves. The UK Service Standard says new source code should be made open and reusable unless there is a convincing reason not to. But possession of source code is not the same as operational capacity. An authority may still lack the build system, deployment configuration, dependency inventory, security keys, monitoring rules, data migration tools and staff knowledge needed to run it safely.
Conversely, proprietary software is not automatically ungovernable. A public authority can preserve meaningful control through strong data portability, documented standards-based interfaces, audit rights, source-code escrow or appropriate licensing, testable exit procedures and access to operational evidence. The relevant test is not ideological purity. It is whether another competent team could understand and continue the service under defined conditions.
Identity and registers reveal the full problem
Identity infrastructure is a useful case because it combines convenience, security and public power. A private provider may be well placed to develop cryptography, fraud detection or secure mobile software. The public authority nevertheless has to decide who may rely on the credential, which attributes may be requested, how transactions are logged, how a person switches providers and what alternative exists for someone who cannot or will not use the digital route.
The revised European Digital Identity framework, adopted in 2024, illustrates this mixed model. A wallet may be provided directly by a Member State, under a state mandate or independently and then recognised. The regulation also establishes common interfaces and protocols, requires the user-facing application software to be open-source licensed subject to limited exceptions, provides for transaction-history visibility and supports data portability. It also requires access to public and private services not to be made dependent on using the wallet. These provisions do not guarantee flawless implementation, but they show how private provision can sit inside public rules designed to preserve choice, scrutiny and switching.
Registers make the governance challenge sharper. An authoritative register is not simply a database that happens to be accurate. It is a legally and organisationally defined source whose records have recognised consequences. If a vendor supplies the register platform, the authority still needs control over data definitions, correction procedures, provenance and retention. It must be possible to distinguish the original record, later amendments, derived attributes and the decisions that consumed them.
An access log helps, but observability goes further. The authority needs to reconstruct a consequential event: which identity authenticated, which source was queried, what version of a rule ran, which data was returned, whether a human intervened, what notice was issued and what happened after a correction. That record must be intelligible to investigators, caseworkers and affected people, not only to the supplier’s engineers. It also has to avoid becoming an indiscriminate surveillance store. Purpose limitation, access controls and retention rules belong inside the observability design.
The strongest case for vendors
The strongest argument for private vendors is not that government should behave like a technology company. It is that reliable digital infrastructure requires deep specialisation. Security operations run continuously. Identity systems face changing threats. Cloud platforms, databases and networks benefit from scale. Experienced suppliers can provide tested tooling, scarce engineering talent, established incident processes and contractual support that a small public body would struggle to reproduce.
Public ownership does not guarantee competence. A forced insourcing programme can leave an authority with ageing systems, hard-to-recruit teams and diffuse responsibility. Multiple suppliers can also create seams no one owns. If every component has a different contract, failures at the interfaces may prompt each vendor to prove that the fault lies elsewhere. A single integrator can sometimes provide clearer operational accountability and faster delivery.
This counterargument should change the design, not end the inquiry. The objective is not supplier exclusion but capable commissioning. A sustainable model may combine public ownership of architecture, rules, risk and institutional knowledge with private delivery of components and operations. The authority needs enough technical depth to be an intelligent customer, enough operational access to test claims and enough retained staff to take charge during a dispute or transition. The supplier’s expertise should increase public capability rather than substitute for it permanently.
A contract cannot perform an exit
Many lock-in problems are visible before procurement but are priced as future inconveniences. Data is exportable, but only in a vendor-specific format. Interfaces exist, but their rate limits make migration impractical. The authority owns its records, but not the configuration that gives them meaning. An audit right exists, but excludes subcontractors or essential telemetry. Source code is held in escrow, but no independent team has proved that it builds.
Contracts still matter because they allocate the rights and obligations needed for continuity. They should define data and configuration export, open formats, interface documentation, audit evidence, incident reporting, supply-chain visibility, intellectual-property permissions, knowledge transfer, staffing continuity and the responsibilities of an outgoing supplier. They should also cover financial distress and emergency access, not only an orderly handover at the end of term.
The UK government’s Digital, Data and Technology Playbook treats exit planning as an early activity, not a final procurement task. Its guidance calls for defined data-return obligations, open formats and documented APIs, joint planning between outgoing and incoming teams, and consideration of dual running. This is practical recognition that a right to switch has little value if exercising it interrupts a public service.
Replaceability therefore has to be rehearsed. Can the authority restore the service from backups in an independently controlled environment? Can it export records, configuration and audit histories with their meanings intact? Can a second team build the software from the available source and documentation? Can one component be substituted without rewriting the rest? Can operations continue through a supplier outage, legal dispute or insolvency? A successful rehearsal produces evidence that contract wording cannot.
Human review depends on technical control
For the person at the counter, all of this architecture becomes one practical question: can the institution explain and correct what happened? A meaningful route to challenge a decision requires more than a button marked “appeal”. The notice must identify the relevant decision and evidence. Staff must be able to see the data lineage and rule version. A correction at the source must propagate, and the case must be reconsidered rather than merely annotated. A non-digital or assisted route must remain for people who cannot complete the standard flow.
This is why a citizen control panel for government data cannot be only a polished front end. Its promises depend on the deeper system: authoritative sources, understandable access records, correction workflows and institutional responsibility. A dashboard that exposes data without giving anyone power to repair its consequences may make failure more visible without making the citizen more capable.
Public oversight also needs its own access. Auditors, ombuds institutions, courts and elected bodies should not depend entirely on a vendor’s account of system behaviour. That does not mean opening sensitive production systems indiscriminately. It means designing evidence, permissions and independent expertise so that authorised scrutiny is technically possible. Responsibility without observability is ceremonial; observability without the competence to interpret it is equally weak.
The capability that must remain public
A public authority does not need to know every line of code. It does need to know enough to locate failure, assess risk, challenge a supplier and make a credible change. That capability lives in people as much as documents. Architects, service owners, security specialists, policy experts and frontline staff need shared knowledge of how legal rules become data flows and operational actions. If every experienced person transfers to the supplier, even perfect documentation may become unreadable at the moment it is needed.
Maintaining that capacity costs money, and some duplication is intentional. A secondary operating route, migration environment or internal technical team can look inefficient during calm periods. Its value appears during an outage, a policy change, a security incident or a failed contract. Resilience is the preserved option to act when the normal arrangement no longer works.
If you value careful reporting on the machinery behind public decisions, you can subscribe to Alkemata for future essays on human-centred infrastructure.
The unresolved choice is therefore not simply whether government should build or buy. It is how much permanent competence, evidence and operational freedom an authority must fund so that a supplier relationship remains genuinely replaceable. The answer will vary by service, but the proof should be concrete: successful recovery, migration and substitution exercises, alongside correction and appeal journeys that work for real people. Until those capabilities have been demonstrated, assurances of control are still vendor claims and contractual intentions, not public infrastructure that can safely outlast its supplier.