UNDER CONSTRUCTION — WORK IN PROGRESS
This page forms part of a developing public proof of concept. Content, structure and illustrations may change as the project develops.
WORK IN PROGRESS — THE ENGINEERING APPROACH
The Engineering Approach
Before you improve a system, you have to understand how it actually behaves.
Rewiring the Public Sector starts from first principles. It asks what the system is meant to achieve, what information must move through it, where responsibility sits, how outcomes are verified, what happens when reality differs from expectation, and how learning travels back through the organisation.
These are engineering questions before they are management questions.
Explore the approach: Ownership · Feedback · Verification · TIRR · Variance · Cascade effects · Headroom · Learning · AI and judgement
1. Orphaned Outcomes
Definition: an adverse or unresolved outcome for which no institution takes continuing ownership after its own process ends.
This shifts the question from “Did each organisation complete its task?” to “Does the real-world consequence have an owner and a route to resolution?”
A system can consist entirely of organisations that have completed their processes correctly and still produce a failed outcome.
2. Closing the Loop
In a closed-loop system, the process does not end when an action has been recorded. It continues through cause, ownership, implementation, independent verification and effectiveness review.
A recommendation, apology, procedure change or completed action is not enough unless the result is checked.
Acknowledgement is not corrective action. Completion is not effectiveness.
3. Independent Verification
Independent verification asks whether the promised action actually happened. Effectiveness review asks the harder question: did it solve the problem and reduce the chance of recurrence?
This separates delivery from assurance and reduces the risk of organisations effectively marking their own homework.
The accountability diagram above shows the separation between taking action and checking its result.
4. TIRR — Trusted Information Recovery and Retiming
TIRR is an information-assurance process designed to reduce the risk that incomplete, contradictory or unreliable information is treated as settled fact.
The current sequence is:
- Recover the original record, sequence and history.
- Reconcile versions, dates and sources.
- Independently check completeness, context and reliability.
- Release or escalate depending on whether the information is sufficiently trustworthy.
The point is simple: before a person, rule set, database or AI system acts on information, ask whether the information is trustworthy enough to use at all.
Basic information design still matters
Not every information failure requires advanced technology to solve it. Some are matters of basic common sense.
Document titles should be written for retrieval by the recipient, not merely for the sender’s internal filing system. A reference such as an internal case number may be useful to the organisation, but a title should also tell a person what the document is, who sent it and when it was received. Good naming reduces the need to reopen documents simply to discover their purpose.
The same applies to email. A subject line should preserve the subject matter of the conversation. Long chains of “Re: Re: Re:” may retain chronology, but they progressively weaken retrieval and context. A clear subject line should still make sense months later, without requiring the reader to reconstruct the thread.
Information is not useful merely because it exists. It must remain intelligible and retrievable over time.
This is not an AI problem. AI may help search badly organised information, but it should not be used as an excuse for poor information architecture in the first place.
5. Variance Explanation
When actual outcomes differ from expected outcomes, the difference should be explained rather than merely reported.
That requires attention to causation, alternative explanations, uncertainty, comparability and changes in the measurement system itself.
In engineering terms, a change in the reading is not automatically a change in the underlying system. The measurement method may also have changed.
6. Cascade Amplification
A small initial error, assumption or classification can become more consequential as it passes through interconnected organisations, records and decisions.
The output of one system becomes the input to another. Each handover can add authority, metadata or further action. A minor defect at the start can therefore acquire disproportionate weight downstream.
7. Headroom and Derating
Engineering systems are not normally designed to operate continuously at their absolute theoretical maximum. They require spare capacity for variation, abnormal demand, fault recovery and uncertainty.
The same principle matters in public services. Unused capacity is not necessarily waste. Sometimes it is resilience.
Maximum capacity is not the same as optimum performance.
8. Continuous Improvement
Failure should change the system.
Continuous improvement is not a promise that “lessons will be learned”. It is a disciplined sequence in which the failure is understood, corrective action is implemented, the result is verified and the effectiveness of the change is reviewed.
The distinction matters because administrative closure can look complete while the underlying failure remains untouched.
Return to the closed-loop model: learning becomes useful when the resulting change is tested and the evidence feeds into the next decision.
9. AI as an amplifier, not a substitute for judgement
Rewiring the Public Sector is not an AI book. The public sector is partly digital, partly analogue and entirely human.
The same diagnostic principles must work whether information travels through a handwritten form, a telephone call, a court extract, an email, an internal database or an AI-enabled service.
AI can strengthen memory, pattern recognition, analysis and comparison. But it can also automate a broken process.
Don’t digitise the failure. Understand the system first.
The engineering test
Across all of these ideas, the practical test remains the same:
- What is the system supposed to achieve?
- What information does it rely on?
- Where are the interfaces and handovers?
- Who owns the outcome?
- How is failure detected?
- How is corrective action verified?
- How do we know the change actually worked?
- How does the learning travel back through the system?
The aim is not to add another layer of theory. It is to understand how the system behaves, where it fails, and how it can be rewired to learn.
