A system often explains itself most clearly when something goes wrong.
Normal operation hides dependencies. A train arrives, a card payment clears, a school day begins, water comes from the tap. The smooth result makes the supporting machinery disappear.
Failure brings those dependencies back into view.
That is why eduKateSG’s How X Works programme treats failure mapping as part of explanation rather than a separate appendix.
Failure Mapping Is Not a List of Things That Can Go Wrong
A risk list is useful, but a failure map does something different. It traces sequence.
What breaks first? What state changes because of that break? Which dependency receives the disturbance? Does the disturbance stop locally, or does it propagate? When does the receiver notice? Which recovery action is still available?
The map turns “failure” from a label into a mechanism.
Step 1: Establish Normal Operation
You cannot identify failure without defining what success was supposed to look like.
- What function is required?
- For whom?
- At what quality?
- Within what time?
- Under what load?
- With what safety margin?
A railway can be “working” in the sense that trains move, yet fail its service objective if headways become unusable. A learner can be “doing practice” yet fail the learning objective if every answer depends on immediate prompting.
Failure is always relative to a required function.
Step 2: Find the First Unstable Point
The visible problem is often downstream.
A late shipment may begin with inventory not being available when the order was released. A student’s algebra error may begin with weak control of negative numbers. A congested junction may begin with arrival patterns several links upstream.
Failure mapping therefore works backwards until it finds the earliest state that no longer met the conditions required by the next step.
Step 3: Trace Propagation
Some failures are local. Others travel.
A failed light bulb usually remains a local fault. A failed signalling component can constrain an entire railway section. A missing prerequisite in mathematics can reappear across algebra, graphs, geometry and later topics.
The important question is not merely “what else breaks?” but through what dependency does the failure travel?
Common Propagation Paths
- Capacity: one constrained component pushes queues into neighbours.
- Information: one bad reading contaminates later decisions.
- Timing: one delay removes slack from downstream steps.
- Custody: one broken handoff leaves the next system without an owner.
- Trust: one visible failure changes how people interact with the system.
- Resource: one shortage forces substitution or shutdown elsewhere.
Step 4: Find the Receiver
Engineers, operators and institutions often see failure before the public does. Sometimes the reverse happens: the user experiences a problem before the monitoring system recognises it.
Failure mapping must therefore identify the receiver and ask when the disturbance becomes meaningful to them.
A one-second delay may be invisible in one system and catastrophic in another. A tiny accounting mismatch may be operationally harmless today but important if it compounds across millions of transactions.
Step 5: Distinguish Failure From Degraded Operation
Real systems rarely have only two states: perfect and broken.
They degrade.
- Normal
- strained
- degraded
- partially unavailable
- failed
- recovering
- stable again
This state ladder matters because the correct response changes with severity. A strained system may need load shedding. A failed system may need isolation. A recovering system may need slower re-entry rather than immediate full demand.
Failure Can Be Safe or Unsafe
Good systems often choose how to fail.
A fire door closes. A circuit breaker opens. A transaction is rejected rather than partially committed. A teacher stops a learner from extending a misunderstood method into harder work.
The system sacrifices some immediate function to protect a more important state.
This is closely connected to How Reliability Works: reliability is not simply avoiding failure; it includes containing and recovering from it.
Worked Example: A Delivery Network
Suppose deliveries begin arriving late.
The visible failure is lateness. The map works backwards:
- Final-mile route left late.
- Staging completed late.
- Inbound linehaul arrived late.
- Origin sort missed a departure window.
- Order volume exceeded the planned sort capacity.
Now the failure is no longer “driver was late.” It is a capacity-and-timing chain.
Worked Example: A Student Suddenly Struggles With Algebra
The visible failure may be an equation solved incorrectly. The first unstable point may sit earlier: negative-number operations, fraction control, reading mathematical symbols or understanding equality.
If we repair only the final answer, the failure returns. If we repair the upstream dependency, several downstream errors may disappear together.
The CivDJ Failure Pass
- Forward: inject the disturbance and watch where it travels.
- Backward: start from the observed failure and reconstruct the earliest unstable state.
- Rotate: compare operator, receiver, maintainer and regulator views of “failure.”
The rotation is important because different receivers can have different thresholds. What an operator calls “degraded but available” may be functionally unavailable to a wheelchair user, a novice learner or a customer at the edge of a service area.
A Failure Map Should End With Repairability
Understanding why something broke is only half the job.
Can the failed component be isolated? Is there redundancy? Can work be rerouted? Is data sufficient to reconstruct the last known good state? What must be verified before normal operation resumes?
At Singapore scale, this containment-and-rerouting question becomes part of What Makes Singapore Work | The Spare Route. Once a system is degraded, resilience depends on whether the unstable component can be isolated, whether essential work has another viable path, and whether the alternative avoids the same failure that removed the normal route. This page remains the general mechanism owner for failure mapping.
These questions connect failure mapping directly to repair routing.
At Singapore scale, this failure-to-learning path becomes part of What Makes Singapore Work | The Learning Loop. A fault, incident or degraded state becomes useful institutional information only when its propagation and receiver consequence are reconstructed clearly enough to change diagnosis, controls or the next decision—and then tested against what happens after the change. This page remains the general mechanism owner for failure mapping.
Failure is information. The important question is whether the system is designed to read it.
Why Failure Belongs in a Civilisation Blueprint
A civilisation that can explain only normal operation understands itself incompletely.
Resilience depends on knowing which functions are critical, where dependencies concentrate, what can fail locally, what propagates, who becomes vulnerable first and how recovery returns the system to a verified state.
Return to How X Works to follow failure, reliability, coordination, infrastructure and repair across the wider map.