WORK IN PROGRESS — REAL-WORLD EXAMPLES

Real-World Examples

Systems thinking becomes useful only when it survives contact with reality.

Rewiring the Public Sector uses practical examples not as decoration, but as evidence. The aim is to reconstruct enough of the system to ask what each organisation could see, what the citizen or service user experienced, where information crossed boundaries, where ownership weakened, and what an engineering interpretation suggests should change.

The examples below are working case studies for the private proof of concept. Some are well developed; others remain candidates that require further verification before any public use.

---

1. Justice: when an outcome does not close the system

The project’s central personal case began with an eleven-second event and eventually exposed a much larger systems question: what happens after an authoritative outcome has been reached, but records, restrictions, complaints, reputational consequences and institutional responsibilities remain distributed across different organisations?

The engineering interest is not simply in the original incident. It is in the cascade amplification that follows when one decision, classification or record becomes the input to several downstream systems.

Diagnostic questions:

• What information existed at each stage?
• Who owned it?
• Where did it travel?
• What changed after the final outcome?
• Did every downstream record reflect that outcome?
• Who owned restoration and learning after the process ended?

Engineering interpretation: this is a problem of information integrity, handover control, orphaned outcomes and closed-loop verification.

Potential visuals: The Orphaned Outcome; Justice Information Audit; Disconnected Records.

2. NHS access: the 8 am GP appointment race

A simple personal example raises a larger measurement problem. Calling promptly at 8 am can still leave a patient several places back in the telephone queue, and same-day appointments may be gone within a short period. A failed attempt can end with a familiar instruction: “Phone again tomorrow.”

The systems question is not merely whether the appointment slots were allocated efficiently. It is what happens to the demand that could not be met.

• Is an unsuccessful request recorded?
• Does unmet demand disappear when the queue resets?
• Is there triage or safety-netting?
• How much patient effort is consumed by repeated attempts?
• Is access measured by appointments issued, or by clinical need successfully resolved?

Engineering interpretation: a system can optimise the visible queue while failing to measure the load that never reaches the formal process.

3. Digital access: when automation becomes another interface

A separate NHS example concerns automated reception technology. Reported difficulties around speech recognition, date-of-birth entry, accents, older callers and handoff to a human receptionist illustrate an important principle: introducing a digital interface does not remove the need to design for exceptions.

This is not evidence that automated reception is inherently unsafe or ineffective. It is a reminder that a system must be judged by how it handles both the normal path and the people who do not fit it neatly.

Engineering interpretation: robust systems require fallback paths, human override and deliberate treatment of edge cases.

Digitising bureaucracy does not necessarily remove bureaucracy. It can simply make bureaucracy run faster.

4. Fraud prevention: closing the data-matching loop

Audit Wales’s work on the National Fraud Initiative provides a useful example of data matching as a system rather than a one-off technical exercise. The reported Welsh outcomes for the 2024–26 exercise totalled £8.7 million across fraud, overpayment and error, with £1.1 million attributed to recording corrections following review.

The more important systems point is that auditors also identified opportunities to improve timely follow-up of matches, recording of activity and outcomes, local reporting and the use of application checking to prevent problems earlier.

Engineering interpretation: detection is only the first stage. A closed loop requires ownership, investigation, recorded outcome, verification and feedback into prevention.

5. Infrastructure: announced capacity versus deliverable capacity

A proposed AI data-centre development at Chapelcross raised a classic engineering question: what does a headline capacity figure actually mean?

Preliminary review of the public material did not establish, at that stage, a secured 1 GW electricity supply, a firm energisation date or contracted renewable capacity. The case was therefore retained as a low-priority example rather than treated as a settled finding.

The wider lesson is important. Announced capacity, theoretical capacity, contracted capacity and deliverable capacity are not the same thing.

Engineering interpretation: specify the measurement point, operating condition and assurance level before comparing numbers or making strategic decisions.

6. Piper Alpha: information, responsibility and independent assurance

Piper Alpha remains a defining safety-system reference because it demonstrates how severe consequences can arise when critical information, responsibilities and organisational interfaces fail to connect.

The relevance to this project is not to claim that ordinary public administration is equivalent to offshore process safety. It is to ask what transferable disciplines emerged from safety-critical engineering: reliable information, clear ownership, independent assurance, controlled handovers and learning that changes the system.

This is the background to the TIRR concept — Recover → Reconcile → Independently check → Release or escalate — as an information-assurance approach for modern public systems.

Potential visual: Project Piper Alpha — Trusted Information / TIRR infographic.

---

A common diagnostic pattern

Across very different sectors, each case can be tested using the same sequence:

1. The event and factual context.
2. What each organisation or participant could see at the time.
3. What the citizen or service user experienced.
4. The system boundary and handover points.
5. The information that crossed those boundaries and its provenance.
6. The failure mode or mismatch.
7. Why existing controls did not correct it.
8. The engineering interpretation.
9. The redesigned control, ownership or verification mechanism.

The examples differ. The diagnostic questions remain remarkably consistent.

The evidence rule

The project deliberately keeps more case material in reserve than will appear in the final book or website. The working rule is:

Research widely. Preserve the evidence. Select the strongest examples. Edit ruthlessly. Retain the unused material.

That is headroom in practice: the evidence base should be larger than the final presentation.