How Nothing Causes the Worst Disasters#
We are trained to worry about what people do. Bad code, bad actors, bad decisions. Almost nobody worries about what is absent, because for reasons of efficiency, the typical absence feels like zero — like neutral, like nothing happening. Yet, nothing could be further from the truth.
Here are three cases where nothing did the damage. They are three very different sizes of the same structural problem shape.
Nothing, almost killing a website by missing a required version#
Three days ago I published an update to this site for the first time after weeks. The build passed, every page rendered — but every navigation menu stopped working for mobile browsers. The button was still there; hovering still showed its label. Pressing it did nothing.
Nothing in the site had changed. Not one line of the code that draws those menus.
What broke the website was a required version I had not written down. My setup asked for a display theme, “version 1.1 or newer, below 2” — an ordinary way to say it. My own machine had 1.1.4 and worked fine. The build server installs fresh every time, and by September the newest version below 2 was 1.4.0. So the site was built with a theme six releases past anything I had tested, which required a newer version of its underlying theme, which had removed the mechanism the button depends on.
The button was left holding a switch with nothing on the other end.
The missing thing was not code. It was information that was never recorded: which version this site had actually been tested against. The fix was one line. The lesson is that when nothing is wrong and nothing changes, beware, because nothing can kill everything. The gap cost nothing to leave open and everything to discover. The safe solution? Pinning down nothing to a specific semantics organizing nothing in order to destroy the deadly ambiguity implied in nothing. In other words: The fix is to say exactly which version was tested — to replace an ambiguous nothing with a specific something.
Nothing killing real-world systems in the tech-world#
On 19 July 2024, roughly 8.5 million Windows machines crashed at once with a blue screen of death — hospitals, banks, broadcasters, 5,078 flights cancelled in a day, over $5 billion in direct losses to Fortune 500 firms alone. It is still described as the largest IT outage in history, though “largest” there means simultaneous scope: no deaths were directly attributed to it.
The natural assumption is that somebody skipped the testing — that a half-baked build escaped into the world. That is not what happened, and the truth is stranger. The update was tested. It went through CrowdStrike’s testing, and it passed.
Two parts of CrowdStrike’s system disagreed about how many fields one file contained. One expected twenty-one. The other supplied twenty. The program reached for the twenty-first field, found nothing there, and read whatever happened to sit next to it in memory as though that were the value — inside the Windows kernel, where mistakes are not survivable.
That is the sentence worth keeping:
The absence of a value was not detected as absence. It was read as if nothing were a value. Then ambiguous semantics of nothing created the disaster.
Two more absences made it lethal. There was no bounds check — nothing that said “field twenty-one is missing, stop.” And the file’s validator contained a logic error, so it raised no objection. A check that fails to object and a check that approves produce exactly the same signal. Nobody could tell them apart, including CrowdStrike.
And the sharpest one, from their own report: there was no test for the twenty-first field. The mismatch survived release testing, stress testing, and several successful deployments, because nothing in the suite ever exercised that case. The tests did not fail. The test that would have failed did not exist — which looks identical, from the outside, to a clean run.
One more thing, and it is the part I would put on a wall. That file was not program code; it was configuration of context. So it traveled the fast channel — no staged rollout, no customer rings, and no way for a subscriber to delay installation. CrowdStrike’s real program updates did get all those protections. The danger was not that config is unversioned. It is that config gets the privileges of code and the ceremony of data. Customers were denied the one move that could have saved them: pin the change, and wait.
This CrowdStrike mistake was the largest public outage so far by scope.
The deadliest case is worse, and it was also nobody’s attack. Boeing’s 737 MAX airplane got bigger engines that changed how it handled, so the MCAS system was added to make it fly like the older model — which meant airlines would not have to retrain pilots. A cost decision, not a malicious one. Then: the plane had two angle-of-attack sensors and MCAS read only one, because using both would have triggered a need for extra certification. Finally, the system change was judged too minor for the manual, so pilots were told nothing about it at all. Then under some rare circumstances pilots found themselves fighting the MCAS system they did not even know existed. 346 people died in two crashes, in 2018 and 2019.
This genre is enormous, and I will not pad the page with it: a rocket lost in 37 seconds to an assumption nobody restated (Ariane 5, 1996); a firm destroyed in 45 minutes by an update that reached seven servers out of eight (Knight Capital, 2012; SEC Release No. 34-70694). Every decade supplies more, and almost none of them are attacks. They are gaps nobody wrote down, because it was more “efficient” to take the shortcut of saying nothing about nothing.
Nothing killing civilizations#
On 12 September 2026 — two days ago — Dario Amodei published We Must Pace the Frontier. Its central sentence is not hedged: “We must slow the pace at which we improve the capabilities of AI models.” He puts a number on the near term, warning that within 6–12 months a misaligned swarm could take over the internet with a persistent botnet. Sam Altman agreed; so did Elon Musk (NBC News, free to read). Three people long at odds, saying the same thing.
I want to state the connection narrowly, because the wide version is easy to dismiss and I would rather make a claim that survives attack. I am not saying CrowdStrike was an AI failure. It was a deterministic bug in a kernel driver where nothing was allowed to make decisions.
The narrow claim is this. The property that failed was never intelligence. It was scope of change divided by speed of checking. A system does not need to be malicious, or even wrong, to cause harm at that scale. It needs only to be deployed everywhere at once — which is exactly what makes such systems worth building. Uniform reach is the feature that removes the brakes.
And the absence carries over exactly. For years, on both accidental nuclear winter and on AI, nobody with standing called for a stop by warning about their ambiguous semantics of nothing. Systems that hear no objection proceed as though they had heard approval. Silence gets banked as consent. That is the same failure as the validator that did not object: a missing check is indistinguishable from a passing one.
Which is why this week matters more than it looks. Yet another vital signal now changed from silence to objection. Whether an industry built for uniform reach can still act on an objection is the open question — and it is the same question CrowdStrike’s customers faced when they could not say not yet to an upgrade, and could only watch.
And here I have to declare an interest, because the next paragraph is about my own work and you should discount it accordingly.
“Pace the frontier” is, so far, a direction rather than a quantity. Amodei’s essay does propose real machinery — embedded third-party evaluators with employee-level access — but it does not say what rate is sustainable, measured against what, or how anyone would know they had it right. That is a missing number in an argument about slowing down: another nothing, sitting exactly where the hard part is.
Filling that gap is what the Matheo Study Series is for. Its claim is that an innovation economy has two attractors — one compounding into self-destruction, one staying correctable — and that what separates them is not good intentions but cycle structure: a rate of building bounded by a rhythm of stopping, checking and resetting, from the small 6:1 Shabbat pattern up to the multi-scale Jubilee System (Matheo-b14). Matheo-b12 explains the mechanism by which unpaced building destroys itself; Matheo-b17 explains the reason the most capable agent is the least correctable one — which is the AI case stated in general form, and was written long before this week.
If that is right, then pacing the frontier is not a moral appeal for restraint. It is a stability condition — something with a shape you can compute with, argue about, and be wrong about in public, rather than merely agree to in private. And a model of pacing for innovation economies in general is a model of pacing for AI by implication, because AI is merely an innovation economy running unusually fast.
If the model proposed in the Matheo Series is wrong, the mathematics is public and I would rather be shown the error than agreed with. That is the entire point of #AuditTheMath.
The ability to define a reliable, open testing cycle is essential. A system that cannot specify the detail in a way that anyone can check has no brakes, only undefined outcomes. Hence, transparent testing is essential, starting with this site, making the claim. If that claim is correct, then it will take all of humanity to work together on implementing such testing properly if the AI Dilemma is to be solved by keeping AI from destroying humanity.
Therefore, every paper on this site must stay correctable. The ResearchCity proposed here must stay correctable. I must stay correctable.
Nothing is not neutral because the ambiguous semantics of nothing can turn deadly without warning. Let’s go and look for what is missing.
Offered not to be believed, but to be checked.
Check rather than trust. CrowdStrike’s own account is the primary document: Root Cause Analysis — Channel File 291 (PDF); for an overview, TechTarget or Wikipedia. For the 737 MAX, a peer-reviewed account is The Boeing 737 MAX: Lessons for Engineering Ethics; MIT Sloan’s case study is a shorter way in. More details are here , here , here , and here .
Amodei’s essay is linked above, and so is free coverage of it.
The broken-menu incident on this site is in this repository’s commit history and in the
pinning note in requirements.txt. #AuditTheMath