Early warning
Can you see where it is fragile?
After a serious failure, the review almost always finds that the warnings were there. A maintenance ticket that stayed open for months. A supplier that started missing delivery dates. A specialist who left and was not replaced. A small outage that recovered on its own and was closed as resolved.
Each of these was recorded somewhere. Each, on its own, looked routine. They sat in different systems, owned by different teams, reported to different managers. Nobody was looking at them together, and nobody was looking at them as signs that the same function was becoming fragile.
This is the problem we mean by early warning. It is not a shortage of information. Most institutions collect more data than they can use. It is the ability to see fragility building up around an essential function before it surfaces as a failure.
Our position is simple to state. Failures are rarely sudden. They are assembled from warnings nobody put together. Early warning is the discipline of putting them together: noticing when weaknesses in different domains begin to align, and which way they are moving.
Most warnings were already there
Hindsight makes warnings look obvious. At the time, they rarely are.
The reason is not that people are careless. It is that each signal arrives inside a context that makes it look normal. A delayed repair is one item in a backlog. A missed delivery is one line in a supplier report. A departure is one entry in a staff system. Each is handled correctly by the process that owns it.
What no single process sees is the pattern across them. The sociologist Diane Vaughan, studying the Challenger disaster, described how organisations gradually come to accept small deviations as normal because each one, taken alone, did not lead to disaster. The deviation becomes the baseline, and the next one is measured against it.
Early warning starts by accepting that the signals usually exist. The question is where they are, who can see them together, and what makes them look routine.
More data is not more visibility
The instinctive response to a missed warning is to collect more: more sensors, more dashboards, more reporting lines. It rarely helps. It often makes things worse, because each new stream adds noise faster than it adds understanding.
We distinguish information collection from structural understanding. Collection answers the question “what is happening here?” Structural understanding answers a different one: “why does this system behave the way it does, and where is it becoming fragile?”
The difference is practical. A dashboard can show that every indicator is within its threshold. Structural understanding can show that the thresholds were set for a system that no longer exists, or that several indicators within their thresholds are moving together in the wrong direction.
The value is not in owning every signal. It is in normalising different kinds of evidence well enough to compare them, and in knowing which combinations matter.
Signals matter when they align around a function
A communications anomaly may be routine. So may a power irregularity, a logistics delay or a change of supplier. The same four appearing around the same essential function, in the same period, are not.
This is why early warning, like resilience, starts from the function rather than from the data source. Once the function is named, it becomes possible to ask which signals from which domains bear on it, and to look for convergence rather than for individual thresholds being crossed.
The domains are rarely only technical. The signals that matter for a function can come from infrastructure, operations, suppliers, staffing, budgets, procedures and institutional decisions. A warning system that only watches the technical layer will miss the moment when the specialist who knows how to recover the system hands in her notice.
Charles Perrow described how failures in tightly coupled systems spread faster than operators can understand them. Early warning is the attempt to see the coupling before the failure travels along it.
Direction matters more than position
A static score tells you where something stands. It does not tell you which way it is going.
An institution in reasonable shape but steadily weakening may be at greater risk than one in poor shape but improving quickly. A single assessment will rank them the other way round. That is why we pay as much attention to trajectory as to state.
In practice, this means separating two kinds of evidence:
- Slower structural indicators: staffing depth, maintenance backlog, supplier concentration, budget stability, the age of critical systems. They change over months and show whether the foundation is strengthening or eroding.
- Faster operational signals: incidents, near misses, delays, anomalies, complaints. They change over days and show how the system behaves under current load.
Neither is enough on its own. A slow erosion can stay invisible in operational data until the day it is not. A burst of operational noise can look alarming while the foundation is sound.
When a real event tests a known weakness, that is the moment to reassess, not at the next scheduled review. An incident is also evidence about the warning system: did it see this coming, and if not, why not?
The absence of a signal is a signal
Some of the most important warnings are silences.
A system that has reported no incidents for three years may be exceptionally reliable. It may also have stopped reporting. A supplier that never raises problems may have none, or may have learned that raising them is unwelcome. A maintenance log with no entries may mean nothing needed doing, or that nobody is doing it.
We therefore treat missing signals as something to explain, not as reassurance. Where a signal should exist and does not, the first question is whether the channel that should carry it still works.
This matters most in the places where failure is least expected. The function everyone assumes is stable is often the one nobody is watching.
Compare mechanisms, not organisations
Institutions differ in structure from one country, sector or authority to the next. The ways in which they fail are more similar than their organisation charts.
A function can be weakened by the same mechanisms in very different settings: responsibility separated from capability, a single point of knowledge, a procedure that assumes a channel that may fail, a decision that needs an approval nobody can give in time. These mechanisms recur regardless of who is in charge.
That is why we compare failure mechanisms rather than institutions. The useful question is not “which organisation is better?” It is “which recurring mechanism is becoming active in this function, and what evidence shows its direction?”
This also keeps early warning away from something it should never become: a league table. Ranking institutions invites defensiveness and gaming. Identifying mechanisms invites repair.
A warning is a claim too
A warning asserts that something is becoming fragile. Like any claim, it needs to state what it rests on.
A useful warning says which function it concerns, which signals support it, what kind of evidence those signals are, how confident the assessment is, and what remains unknown. It also says what would confirm it and what would dismiss it.
False alarms have a cost. Each one makes the next warning easier to ignore. A warning system that cannot distinguish a real convergence from coincidence will train its audience to stop listening.
This is where early warning depends on judgement. The people who receive a warning need to be able to judge it: to ask what it rests on, to recognise when evidence is thin, and to know which additional signal would settle the matter. The systems that produce warnings need the same discipline, keeping declared information, observed data and inference apart, rather than blending them into a single score that hides what each one proves.
A warning is only useful if someone can act
Seeing fragility early is worth little if nobody has the authority to respond, or if the response has to be invented at the moment of warning.
For each function worth watching, we want to know in advance: who receives the warning, who can act on it, what actions are available at each level of concern, and what happens if the warning turns out to be wrong. A warning that reaches someone without authority, or reaches the right person with no agreed response, becomes another signal filed as routine.
The link to Resilience is direct. Early warning tells an institution when to prepare. Resilience determines what it can do when preparation meets the event.
European regulation uses the words “early warning” for something different. Under NIS2, an early warning is a notification sent to the authorities within 24 hours of becoming aware of a significant incident. That obligation matters, but it begins after the incident. The early warning we mean begins before it.
How we work on it together
Our work on early warning with a partner begins with the functions that matter most, not with the data that happens to be available.
Name the functions. Agree which essential functions an institution most needs to see clearly.
Map where the signals are. For each function, identify which domains produce relevant evidence, who holds it, and where the silences are.
Define what convergence looks like. Decide which combinations of signals, and which directions of travel, would warrant attention.
Agree the response. Establish who receives a warning, who can act, and what the options are before a warning is needed.
Leave the ability to judge. The institution should end with people who can read the next warning critically, and ask what it rests on.
When we look at a function together with a partner, these are the questions we typically work through:
| Question | What it reveals |
|---|---|
| Which signals from which domains bear on this function? | Whether the view extends beyond the technical layer. |
| Who holds each signal, and who sees them together? | Whether convergence can be noticed at all. |
| Which signals are slow and structural, which fast and operational? | Whether trajectory is visible, not only state. |
| Where should there be a signal and there is none? | Silences that need explaining. |
| Which recurring failure mechanisms are relevant here? | What to look for, independent of organisation. |
| What would confirm or dismiss a warning? | Whether warnings can be judged, not only received. |
| Who can act, and with what options? | Whether a warning can change anything. |
Where we are careful
We hold ourselves to a few commitments about what we claim.
We do not present early warning as prediction. It shows where fragility is building up and which way it is moving. It does not say when, or whether, a failure will happen.
We do not rank institutions or assess individuals. We look at mechanisms and functions.
We do not treat the absence of alarms as proof of health, and we do not treat a single signal as a finding.
We do not blend different kinds of evidence into one score that hides what each of them establishes.
And we do not call something an early warning if nobody can act on it.
Further reading
- Directive (EU) 2022/2555 (NIS2), Article 23, on incident reporting, including the early warning to authorities.
- Diane Vaughan, The Challenger Launch Decision (1996).
- Charles Perrow, Normal Accidents (1984).
Related topics: Resilience · Verification · Capability transfer
Changes to this position
- 24 September 2026 — First published.
Material changes are listed here with their date. Corrections of wording or links are not.