Operational Resilience Is Predictability, Not Uptime

A service that works ninety-eight percent of the time, with no way to know which two percent will fail, can be harder to run than one with an honest, bounded limitation.

A service that works ninety-eight percent of the time, with no way to know which two percent will fail, can be harder to run than one with an honest, bounded limitation.

The dashboard says the service is up. The clients whose payments failed this week disagree. Both are right — and that gap is the resilience problem nobody measures.

Consider a recurring operational failure — say, a cross-border payment process that occasionally does not complete. The instinctive response is to ask how often it fails and to treat a low failure rate as reassurance. But the firms that manage these situations well quickly realise that the failure rate was never the real problem. The real problem was that nobody could predict which transactions would fail, or reliably explain why, until after a client had already been affected.

That distinction changes everything about how you escalate, how you build around a service, and how you judge whether it is fit to depend on. Operational resilience is not a measure of how often something works. It is a measure of how confidently you can predict when it will not.

Uptime is an average — and averages hide the failure that matters

Aggregate availability is a comforting number precisely because it averages away the thing you need to see. A service can report excellent uptime while failing unpredictably in ways that inflict real damage, because the failures are rare enough not to move the headline figure but arbitrary enough that no operational process can be built to catch them in advance. The average tells you the service usually works. It tells you nothing about whether you can rely on it for any particular transaction that matters.

The pattern I return to is that executives ask the wrong first question about a struggling service. They ask how reliable it is, meaning how often it works. The more useful question is whether it is dependable — whether the firm can build operating commitments around it, knowing in advance where its limits are. A service with a known, honest boundary is something you can design around. A service that is usually right and unpredictably wrong is something you cannot, because there is no rule that tells you when to intervene.

Resilience is not high availability. It is bounded, predictable behaviour — including predictable failure.

Escalate the pattern, not the incident

This reframing changes how a firm should challenge a supplier. Escalating individual incidents — this payment failed, that transfer did not complete — keeps the conversation trapped in the specific and lets the supplier treat each event as a one-off. The more powerful escalation moves up a hierarchy: from the isolated incident, to the pattern, to the root cause, to the predictability of the failure, to the client impact, and finally to the reputational and commercial risk the firm is carrying on the supplier's behalf.

The decisive move in that hierarchy is predictability. Asking a supplier not why a payment failed but why the firm cannot know in advance which payments will fail reframes the entire relationship. It shifts the burden from the firm — which has been absorbing arbitrary failures and managing the fallout — onto the supplier, which now has to account for why its service cannot be depended upon in a specific, operational sense. Table 1 sets out that escalation ladder.

Table 1 — The resilience escalation ladder: moving a supplier from incident to accountability

The regulator already thinks in these terms

This is not a private operational preference — it aligns with how resilience is regulated. The JFSC guidance, in its treatment of third-party service failure, describes exactly this problem: a tool that stops working, a control that silently weakens, and a process that continues anyway because nobody noticed the dependency had failed. Its response is to treat such services as critical dependencies with defined manual fallbacks and clear triggers for pausing or limiting activity when the tool is unavailable. That is a predictability requirement in all but name: you must know when the service is failing, and you must have a bounded, planned response.

The same logic runs through the guidance's treatment of model drift — a system that degrades quietly until a significant incident forces the issue. The prescribed fix is monitoring, thresholds, and escalation that surface the problem before it becomes an incident. In every case the regulatory instinct is identical to the operational one: an unpredictable, silently-failing service is a worse control risk than one with a known, honest limitation, because you cannot govern what you cannot anticipate.

Why this is the sharper way to think about AI

The reason this operational lesson belongs in a discussion of AI is that AI systems fail in exactly the mode that uptime cannot capture. An AI service does not usually go down. It stays up and produces output — most of which is right, some of which is wrong, and none of which announces which is which. Its aggregate accuracy can look excellent while individual outputs fail unpredictably, in precisely the way an unreliable payment service does. Series 2's work on accuracy made the case for managing errors proportionately rather than pretending they can be eliminated; this is the operating-model corollary.

The dangerous AI system, in other words, is rarely the one that fails visibly. It is the one that is usually right and unpredictably wrong — the one whose failures are rare enough to erode vigilance and arbitrary enough to defeat any simple rule for catching them. Judged on uptime, it looks like a triumph. Judged on predictability, it looks like exactly the kind of dependency that needs a defined fallback and a human trigger before it is trusted with anything material. The metric you choose determines whether you see the risk at all.

Your most-relied-upon service reports strong availability. Can you predict, in advance, which of tomorrow's transactions it will quietly get wrong — or will you find out the way your clients do?

Next: the procurement questions that only surface after the contract is signed — The RFP Questions That Only Appear After Go-Live.

Sources: JFSC, Guidance on the use of AI in Jersey's financial services sector (2026) — Principle 2 (third-party dependency, fallback and resilience) and the illustrative scenarios on third-party outage and model drift; AI Strategy in Jersey FS, Series 2 Part 3 (accuracy and failure management).

Professional disclaimer: The views expressed are my own and are shared for general informational purposes. This content is intentionally non-confidential and does not include proprietary, client-specific, or employer-sensitive information. It is not legal, regulatory, investment, or professional advice; readers should seek appropriate advice for their circumstances.

Financial services leader (20+ years) | Lean Six Sigma Green Belt | London School of Economics (LSE) AI Leadership Accelerator

A version of this article was first published on LinkedIn as part of the Sequence body of work. This is the canonical version.

The views expressed are the author's own and shared for general information. This content is intentionally non-confidential and does not include proprietary, client-specific or employer-sensitive information. It is not legal, regulatory, investment or professional advice. © 2026 Paul Soares. Sequence is the trading name of Sequence Advisory Limited (in formation) · hello@sequenceadvisory.com