Museum Wire
Law 0 · Katie's LawEvery system is shaped by the human drive to do less work. This is not a flaw. It is the economic force that produces all software — and all software failure.Law I · Boundary CollapseWhen data crosses into a system that interprets structure, without being constrained, it becomes executable.2026 IncidentAxios. 70 Million Downloads a Week. North Korea Inside.Law II · Ambient AuthorityWhen a system trusts the presence of a credential instead of verifying the intent behind it, authentication becomes indistinguishable from authorization.AXM-001Set Theory — Membership, Boundaries, and BelongingLaw III · Transitive TrustWhen a system inherits trust from a source it did not verify, the attack surface extends to everything that source touches.2026 IncidentClaude Code — The Accept-Data-Loss FlagLaw IV · Complexity AccretionSystems do not become complex. They accumulate complexity — one reasonable decision at a time — until no single person can hold the whole in their head.Law V · Temporal CouplingCode that assumes sequential execution, stable state, or consistent timing will fail the moment concurrency, scale, or latency proves the assumption wrong.2026 IncidentCopy Fail — 732 Bytes to Root on Every Linux DistributionAXM-002Boolean & Propositional Logic — True, False, and the Excluded MiddleLaw VI · Observer InterferenceWhen the system that monitors health becomes a participant in the system it monitors, observation becomes a failure vector.2025Amazon Kiro — The 13-Hour Outage2025Operation Chrysalis: The Notepad++ Supply Chain Hijack2025Replit Agent — The Vibe Code Wipe2025Shai-Hulud — The npm Worm That Ate Its Own Ecosystem2024Air Canada Chatbot — The Policy That Wasn't2024Change Healthcare — One-Third of US Healthcare, One Missing MFA2024CrowdStrike — The Security Update That Broke the World2024Google Gemini Image Generation — The Six-Day Pause2024XZ Utils — The Two-Year Infiltration20233CX — The Supply Chain That Ate Another Supply Chain2023Amazon Prime Video — The Per-Frame State Machine2023Bing Sydney — The Chatbot That Went Rogue2023Samsung ChatGPT Leak — The Employee Who Pasted the SecretEFFODE · LEGE · INTELLEGELaw 0 · Katie's LawEvery system is shaped by the human drive to do less work. This is not a flaw. It is the economic force that produces all software — and all software failure.Law I · Boundary CollapseWhen data crosses into a system that interprets structure, without being constrained, it becomes executable.2026 IncidentAxios. 70 Million Downloads a Week. North Korea Inside.Law II · Ambient AuthorityWhen a system trusts the presence of a credential instead of verifying the intent behind it, authentication becomes indistinguishable from authorization.AXM-001Set Theory — Membership, Boundaries, and BelongingLaw III · Transitive TrustWhen a system inherits trust from a source it did not verify, the attack surface extends to everything that source touches.2026 IncidentClaude Code — The Accept-Data-Loss FlagLaw IV · Complexity AccretionSystems do not become complex. They accumulate complexity — one reasonable decision at a time — until no single person can hold the whole in their head.Law V · Temporal CouplingCode that assumes sequential execution, stable state, or consistent timing will fail the moment concurrency, scale, or latency proves the assumption wrong.2026 IncidentCopy Fail — 732 Bytes to Root on Every Linux DistributionAXM-002Boolean & Propositional Logic — True, False, and the Excluded MiddleLaw VI · Observer InterferenceWhen the system that monitors health becomes a participant in the system it monitors, observation becomes a failure vector.2025Amazon Kiro — The 13-Hour Outage2025Operation Chrysalis: The Notepad++ Supply Chain Hijack2025Replit Agent — The Vibe Code Wipe2025Shai-Hulud — The npm Worm That Ate Its Own Ecosystem2024Air Canada Chatbot — The Policy That Wasn't2024Change Healthcare — One-Third of US Healthcare, One Missing MFA2024CrowdStrike — The Security Update That Broke the World2024Google Gemini Image Generation — The Six-Day Pause2024XZ Utils — The Two-Year Infiltration20233CX — The Supply Chain That Ate Another Supply Chain2023Amazon Prime Video — The Per-Frame State Machine2023Bing Sydney — The Chatbot That Went Rogue2023Samsung ChatGPT Leak — The Employee Who Pasted the SecretEFFODE · LEGE · INTELLEGE
Keyboard Navigation
W
A
S
D
or arrow keys · M for map · Q to exit
← Back to exhibits
Complexity & PerformanceAxiomAXM-005

Computability & Complexity — What Machines Can and Cannot Do

Some bugs cannot be detected. This is not a limitation of your tools. It's a theorem.

Timeless · Mathematics · 13 min read

Origin

Alan Turing, 1936 ("On Computable Numbers"). Alonzo Church, 1936 (lambda calculus). Kurt Godel, 1931 (incompleteness theorems). Stephen Cook, 1971 (NP-completeness). Andrey Kolmogorov, 1963 (algorithmic complexity).

The Principle

There are problems that no computer can solve. Not because our computers are too slow, not because our algorithms are unoptimized, not because we haven't tried hard enough — but because mathematical proof demonstrates that no algorithm, running on any machine, for any amount of time, can produce the correct answer for all inputs.

There are problems that computers can solve but not quickly. The time required grows so fast with input size that the universe will end before the computation finishes. These are not engineering limitations. They are structural properties of the problems themselves.

Computability theory draws the line between possible and impossible. Complexity theory draws the line between feasible and infeasible. Every software engineer works within these lines, whether they know it or not.

Why This Is Bedrock

The Halting Problem means you cannot build a perfect bug detector. P vs NP means you cannot break modern encryption by brute force. Big-O notation means your algorithm's performance at scale is determined by its mathematical structure, not by how fast your hardware is. These are not opinions. They are theorems. They constrain every piece of software ever written, and ignoring them does not make them go away.

Archaeologist's Note

This pattern has been found in applications built by talented developers at respected organizations across every decade of software history. Its presence in a codebase is not a reflection of the developer who wrote it — it is a reflection of what that developer was taught, what tools they had, and the path that was easiest given what they were taught. The goal is not to find fault. The goal is to find the pattern — before it finds you.

Katie's Law: The developers were not wrong. The shortcut was not wrong. The context changed and the shortcut didn't.

The AbstractionsComputability & Complexity3 / 5
Previous ExhibitMuseum MapNext Exhibit