Keyboard Navigation
W
A
S
D
or arrow keys · M for map · Q to exit
← Back to exhibits
Observability & OpsAxiomAXM-003

Bayesian Probability — Belief, Evidence, and Updating What You Think You Know

Your test suite passed. How confident should you actually be?

Timeless · Mathematics · 11 min read

Origin

Thomas Bayes, 1763 (published posthumously). Formalized by Laplace. The foundation of statistical inference, machine learning, and every decision you make under uncertainty.

The Principle

Bayes' theorem:

``

P(A|B) = P(B|A) × P(A) / P(B)

``

In words: the probability of A given that B is observed equals the probability of observing B given A, times the prior probability of A, divided by the total probability of B.

This is the mathematics of updating beliefs in the presence of evidence. You start with a prior belief — how likely something is before you look. You observe evidence. You update your belief. The updated belief is the posterior. Every rational decision under uncertainty follows this structure, whether the decision-maker knows the formula or not.

In software: your test suite is evidence. Your monitoring alerts are evidence. Your code review findings are evidence. But evidence is not proof. The strength of the evidence depends on the prior probability of what you're looking for, the sensitivity of your detection method, and the base rate of the condition in the population. Get any of these wrong and your "evidence" leads you to the wrong conclusion with high confidence.

Why This Is Bedrock

Every diagnostic system in software engineering — testing, monitoring, alerting, security detection, code analysis — is a Bayesian classifier. Understanding Bayes' theorem is the difference between "all tests pass, so the code is correct" and "all tests pass, so the probability of a defect has decreased by this much, given these assumptions."

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 AxiomsBayesian Probability3 / 4
Previous ExhibitMuseum MapNext Exhibit