Concept
Repair is part of public system design
Public systems need realistic ways to detect, explain, correct, or recover from failures, not only procedures for normal operation.
A system is not only tested by how it works when everything goes right. It is also tested by what happens when something goes wrong.
Repair does not mean that every process can be reopened endlessly, or that every decision becomes negotiable. Public systems need limits, evidence, deadlines, finality, and consistency. In some cases, repair may mean a formal appeal, judicial review, an ombudsman route, a complaint process, or a change to future practice rather than reopening the same decision again. The point is narrower: when a system produces an error, mismatch, or failure that affects people, there should be a realistic way to detect it, explain it, and put it right.
Most public-facing systems are designed around normal operation. A person submits a form. A record is checked. A category is applied. An eligibility condition is assessed. A status is updated. A decision is issued. That standard path matters, because public systems need regularity and predictable procedures.
But no system only encounters standard cases. Information may be wrong, outdated, missing, or mismatched. A person may not fit the available category. A decision may depend on a record from somewhere else. A portal may route a case incorrectly. A notice may tell the person what happened without showing how it can be corrected.
Repair is the capacity of a system to respond when its ordinary route fails. That may mean detecting that something has gone wrong, explaining what happened in terms people can act on, correcting a record, rerouting a case, restoring access, escalating to someone with authority, or noticing patterns of repeated failure.
A complaint route can help reveal where repair is needed, but complaint handling is not the same as repair. A system can record dissatisfaction and still leave the problem untouched. A repair route has to reach the part of the system that can explain, correct, or escalate the problem.
This is why repair belongs in design, not only aftercare. Repair is not only a service issue. It can depend on administrative ownership, technical design, and the legal or procedural limits that decide what can be changed. It also depends on whether responsibility remains visible enough for someone to act. Public-facing systems can be built with clearer ownership, visible correction routes, status explanations, escalation paths, and ways to notice repeated failure. None of this guarantees that every problem will be solved. It makes repair possible rather than improvised.
The issue carries more public weight when a system affects rights, services, public records, official recognition, protection, or access to necessary support.
A practical repair route usually needs several capacities:
- detect that something may have gone wrong;
- explain the problem in terms people can act on;
- correct a record or route where correction is warranted;
- reroute or escalate the case to someone with authority;
- notice and report patterns of repeated failure, rather than treating every case as isolated.
Repair is not an exception to public system design. It is one of the ways public systems remain responsible when their ordinary routes fail.
Lineage
This note draws on repair and maintenance studies and on practical public-service operations guidance.
Sources and further reading
- Steven J. Jackson, “Rethinking Repair” — a core source for understanding breakdown, maintenance and repair as central rather than marginal features of technological life.
- GOV.UK Service Manual, Service Standard — a practical public-service source on operating, improving and iterating services.
- Parliamentary and Health Service Ombudsman, Principles of Good Administration: Putting things right — useful for grounding repair in acknowledgement, explanation, correction, remedy, and improvement when public administration goes wrong.