A hedged 1999 simulation finding became a planning constant, got formally debunked in 2020, and then a decade of NHS data ran the natural experiment. There is no cliff. There is a convex curve, and it is sitting under your fleet too.
In 1999, three researchers at the University of York published a paper in the BMJ that would go on to run the bed policy of the English hospital system for a generation. Bagust, Place and Posnett built a discrete-event stochastic simulation of a hospital absorbing emergency admissions, ran it against fluctuating demand, and reported two findings in careful, hedged language: “Risks are discernible when average bed occupancy rates exceed about 85%,” and an acute hospital “can expect regular bed shortages and periodic bed crises if average bed occupancy rises to 90% or more.”
Notice what that paper is: a simulation, of one modeled hospital configuration, reporting where risk became discernible in that model. Notice what it became: “the 85% rule.” A universal constant, quoted in planning documents, board papers, and a thousand news stories, usually stripped of every caveat the authors wrote. If you work in software, you already know this number's cousin: the “80% CPU” folk threshold that haunts capacity reviews, the utilization ceiling someone quotes in a meeting with no memory of where it came from.
Here is the thing worth knowing about the 85% rule, and it reframes the whole conversation: it has already been formally debunked in the peer-reviewed literature, the debunk is five years old, and the system it governed spent a decade running an accidental natural experiment that shows what actually happens instead. No cliff. Something more interesting, and for anyone who runs computer systems, directly transferable.
In 2020, Nathan Proudlove of Alliance Manchester Business School published a paper in Health Services Management Research whose title does not hedge: “The 85% bed occupancy fallacy.” His target is what he calls “a persistent fallacy of there being a globally applicable optimum average occupancy target, for example 85%.”
The core correction is a category move, and it is the most useful sentence in the literature: occupancy is not a dial you set; it is a reading you get. In Proudlove's terms, the decision input should be the level of access to beds you require (how often a patient arriving needs one and finds none), “and so bed occupancy should be an output.” Occupancy is the consequence of arrival rates and lengths of stay flowing through a fixed stock of beds. What actually exists, for any given hospital, is an access-occupancy trade-off curve: run hotter and you buy worse access, in a smoothly worsening exchange whose exact shape depends on that hospital's size and the burstiness of its demand. Systems with lower demand variability can safely run at higher average occupancy. There is no universal number, because the safe number is a function of things that differ between hospitals.
That is the claim. The decade of NHS data is the demonstration, and the queueing math is the reason. Take them in that order.
If the 85% rule described reality, the English NHS should have fallen off a cliff years ago, because it blew through the threshold years ago and kept climbing.
The occupancy record, as reported by the named analysts who track NHS England's published statistics (the Nuffield Trust, the BMA, the Health Foundation): overnight general-and-acute occupancy reached 92.5% in the final quarter of 2024/25 on the KH03 series; adult general-and-acute occupancy hit 95.7% in the first week of January 2026 on the winter daily sitreps; many trusts regularly exceed 95% in winter. For scale: NICE's guidance treats 90% as a pragmatic maximum, and NHS operational planning has used 92%. The system has been operating at, and past, every version of the red line, continuously, for years.
Now the strain side, and one definitional discipline matters here more than anywhere in this essay, because NHS waiting statistics contain two different “12-hour” metrics that lazy writing merges. The series used in this paragraph, throughout, is waits of more than 12 hours after a decision to admit, so-called trolley waits. On that one series, as compiled by the House of Commons Library and the Nuffield Trust from NHS England's monthly data: in the quarter ending March 2015, just under 1,000 patients waited over 12 hours after a decision to admit. In the quarter ending March 2025, more than 155,000 did. June 2026's monthly figure of roughly 49,000 stands about 107 times its June 2019 counterpart. (A separate metric, waits measured from arrival in A&E, produces even larger absolute numbers: around 136,700 in April 2026, and belongs to a different denominator; do not stack the two, and this essay doesn't.)
Look at the shape of what happened. Occupancy rose by a handful of percentage points: from the high 80s into the low-to-mid 90s. The tail-strain metric rose by two orders of magnitude. And critically, at no point was there a snap: no single winter where the system crossed a line and toppled. Every incremental point of occupancy bought a disproportionately larger increment of misery, smoothly, year over year.
That is not what “a threshold at 85%” predicts. A threshold story predicts a knee: fine on one side, catastrophe on the other. What the record shows is convexity: a curve that is always rising and always steepening, where the last few percentage points of utilization are catastrophically more expensive than the first few, with no special magic at any particular number. The 85% rule failed not because the system tolerated high occupancy (it manifestly did not) but because the failure arrived as compounding curvature rather than a cliff edge with a signpost.
The curve has been sitting in queueing theory since before the NHS existed. In the simplest single-server model (M/M/1, one server, random arrivals), the mean time in the system scales as 1 over (1 minus utilization). The arithmetic is exact and worth internalizing: at 50% utilization, response time is twice the bare service time. At 80%, five times. At 90%, ten times. At 95%, twenty. Each step toward saturation costs more than the last; the function has a vertical asymptote at 100% and no knee anywhere. Folk rules like “flat until 70, painful past 85, unusable at 95” are just points read off this curve and rounded into slogans.
But the single-server curve is also where the folk wisdom goes wrong, in both directions, and this is the essay's payload. A hospital ward is not one server; it is hundreds of beds pooled. A production service is not one replica; it is dozens or thousands. The multi-server model (M/M/c) behaves differently in a way that dissolves the idea of a universal threshold entirely: pooling is forgiving, and the more servers share the load, the hotter you can safely run.
I computed the exact trade-off (standard Erlang-C queueing arithmetic; the numbers below are mine and re-derivable by anyone with the formula). Fix a service target: an arriving customer (a patient needing a bed, a request needing a worker) should face at most a 10% chance of having to wait at all. Now ask: what utilization can a pool sustain while meeting that target?
| Pool size (beds / servers) | Max sustainable utilization at P(wait) ≤ 10% |
|---|---|
| 5 | 46% |
| 20 | 71% |
| 100 | 86% |
| 500 | 94% |
| 1,000 | 96% |
Read that table twice, because it contains the whole argument. At the identical risk target, a 20-bed unit is already in trouble at 75% occupancy, a 100-bed hospital happens to top out almost exactly at the famous 85%, and a 1,000-bed trust can run at 96% with no worse access. The “safe” number spans twenty-five percentage points depending on nothing but pool size: before we even touch demand variability, which shifts every row again. A single universal occupancy threshold is not merely imprecise. It is a category error, like asking for the safe speed of “vehicles.”
(It also explains the rule's eerie durability: 85% really is about right for a mid-sized pooled unit, the kind a 1999 simulation might reasonably model. The number was locally true and globally meaningless, which is the most dangerous kind of true.)
The software translation is one-to-one, and it is the chart to have in hand before anyone in a cost review proposes “optimizing” utilization upward. “We should run the fleet at 85% CPU” is exactly as meaningful as “hospitals should run at 85% occupancy.” That is, meaningless without two more numbers: how many units are pooling the load, and how bursty the arrivals are. A 3-replica service at 80% utilization is running dramatically hotter, in risk terms, than a 500-replica service at 90%. Autoscaling changes the curve; correlated bursts change it; long-tailed service times change it. The utilization number alone predicts nothing, and any SLO conversation conducted purely in utilization percentages is a conversation about the wrong axis. What exists (for your service exactly as for a hospital) is a latency-utilization trade-off curve, specific to your pool size and your traffic's variance, and the honest engineering move is Proudlove's: pick the access target first, then read off what utilization your architecture can afford. Utilization is an output.
One warning against over-learning the lesson, because convexity cuts both ways. Nothing above says “thresholds are fake, run hot.” The NHS record is a demonstration that running in the mid-90s is catastrophically expensive (two orders of magnitude in trolley waits), just not discontinuously so. Convex curves are in some ways worse than cliffs: a cliff announces itself, while curvature lets you boil slowly, each quarter only somewhat worse than the last, with no bright line to rally a decision around. The absence of a knee is not the absence of danger. It is the absence of an alarm.
Which leaves the question that makes this story transferable to every field: how did a hedged, configuration-specific simulation finding become a two-decade planning constant?
Not through any villain. Bagust, Place and Posnett wrote a careful paper; “risks are discernible above about 85%, in this model” is a defensible sentence. What happened next is a pathology every engineer will recognize from their own organization's lore. The finding was compressed for retelling (“85% is the danger line”), the compression was cited instead of the paper, the citation acquired authority through repetition, and within a few years the number was load-bearing in documents written by people who had never seen the simulation, the configuration, or the caveats. The chain from “a modelled risk inflection in one setup” to “the universally optimal occupancy is 85%” is made entirely of small, reasonable acts of summarization, and it ends somewhere the original authors never claimed. Proudlove's 2020 rebuttal has now spent five years failing to dislodge it, because a rebuttal is a paper while the rule is a meme, and memes compound.
Your organization has these numbers too. The connection-pool size someone benchmarked in 2019. The “keep utilization under 80” line in the runbook. The queue-depth alert threshold nobody can source. Some of them encode real, hard-won knowledge about a specific configuration that no longer exists. The audit that this essay suggests is cheap and slightly uncomfortable: for each load-bearing constant in your capacity planning, ask who derived it, on what pool size, under what traffic, and whether anyone has re-derived it since. If the answer is a shrug, you are not following an engineering rule. You are following a citation of a citation of a simulation of someone else's system, and the curve your system actually lives on (convex, knee-less, specific to your scale) is sitting there unplotted.
Plot the curve. Pick the access target. Let utilization be the output. That was the right answer for hospital beds in 1999, it was published as the right answer in 2020, and it is the right answer for your fleet today: no magic number required, because there never was one.
For each load-bearing constant in your capacity planning, ask who derived it, on what pool size, under what traffic, and whether anyone has re-derived it since.
That audit is only possible if your numbers carry their provenance. Chain of Consciousness gives an agent's decisions a tamper-evident record of what was derived, from what inputs, when, and by which run, so a constant that shows up in a runbook two years later can be traced back to the simulation and configuration it actually came from, instead of surviving as a citation of a citation. Plot the curve, pick the access target, and keep the receipts for every number the system runs on.
See Hosted Chain of Consciousness · Read the Theory of Agent Trust
pip install chain-of-consciousness · npm install chain-of-consciousness
Or the whole trust stack at once: pip install agent-trust-stack / npm install agent-trust-stack