We ended the last chapter right on the edge of the most useful trick in the whole subject, so let's not waste the momentum. Conditioning only runs one direction: from a cause to an effect, from the truth to the reading you can actually take. A lab tests a thousand sick people and hands you P(positive | sick). But you never stand in the world of "sick." You stand in the world of "I just got a positive," and what you badly want is P(sick | positive), the arrow pointing the other way. Here is the idea that makes the whole back half of this course possible, and it is almost too simple to believe. Both of those conditionals are secretly built from the same overlap, P(sick and positive) — the chance of both at once, which does not care which word you say first. Solve that one shared term two ways, set the two answers equal, and you can turn the arrow around. That is the flip, and its formal name is Bayes' theorem. To get there cleanly we need one idea first: total probability, the art of finding a hard chance by slicing the world into easy cases and adding them up. Once we have both, we will do the thing this whole machine was built for. We will watch a belief update as evidence lands, one piece at a time. No new axiom in any of it. Just conditioning, read backwards.
01The multiplication law
Start with the one formula we already own. Conditioning said P(A|B) = P(A∩B) / P(B): shrink the world to B, then measure the overlap A∩B as a fraction of it. That is a division, and division is just multiplication in disguise. Clear the denominator by moving the P(B) to the other side and you get something that reads well in plain English: P(A∩B) = P(A|B) · P(B). The chance of both A and B is the chance of the clue B, times the chance of A once you're already inside B. So it is a two-step story. First B happens, then A happens given B. Drag the two factors below and watch the overlap rectangle they carve out grow and shrink.
0.45 × 0.60 = 0.27
aha — P(A|B) = P(A∩B)/P(B); multiply both sides by P(B) and the fraction bar clears: P(A∩B) = P(A|B)·P(B). No new axiom, just algebra.
Fig. 1. Drag P(B) and you're carving the column's width; drag P(A|B) and you're carving the fraction of that same column shaded from the top — not a fraction of the whole square, because once B is given, the column is the new 100%. The gold overlap is P(A∩B), and its area is nothing but width × height. Read the two-step story off the picture: first B happens (the column), then A happens inside B (the shaded slice). Multiply those two fractions and you've re-derived the multiplication law. No new rule was added — you just cleared the fraction bar in the conditioning definition you already knew.
This is the multiplication law, and notice we invented nothing. It is the conditioning definition with the fraction bar cleared. But here is where it gets interesting, and it is the hinge the whole chapter swings on. That overlap A∩B — "both A and B" — does not care which event you name first. "Rain and Tuesday" is the exact same set of days as "Tuesday and rain." So P(A∩B) = P(B∩A), dead equal. That means we can build the very same sliver a second way. Condition on A first instead of B, and you get P(B|A) · P(A). Two roads, one destination. Watch the same overlap assemble both ways below.
same sliver either way = 0.31
aha: P(A∩B) is one fixed number — the order you build it in never changes it.
Fig. 2. The gold sliver is P(A∩B) — one fixed number. Toggle via B and it's built as a tall bar for P(B), with the sliver being the P(A|B) fraction sliced from the bottom. Toggle via A and the same sliver is built as a wide bar for P(A), sliced by P(B|A) instead. Drag the sliders — the two products on the right always land on the same value, because both are just the same overlap, read off in a different order.
Look at what just appeared on screen: P(A|B) · P(B) = P(B|A) · P(A). Both sides are the identical overlap, weighed from two directions. That equation is the entire seed of Bayes' theorem, and everything left to do is divide. We will cash it in shortly. But a conditional like P(A|B) is only easy to write when you can see inside B. Often the event A you care about is tangled across many different worlds at once. So before we flip anything, we need a way to find a stubborn P(A) by breaking it into pieces we can see. That tool is total probability.
02Total probability: the evidence is a sum
Here is the situation total probability solves. Sometimes an event A is hard to measure head-on, but easy the moment you know which scenario you are in. A factory's overall defect rate is murky. But if you know which machine made the part, each machine's rate is on a spec sheet. So the move is to partition the world: chop Ω into a set of cases B₁, B₂, B₃… that are disjoint, meaning no two overlap, and exhaustive, meaning together they cover everything. Every outcome then lands in exactly one case, with no gaps and no double-counting. Watch the sample space get sliced into clean tiles below.
drag a gold boundary to reweight the slices
3 slices · Σ P(Bᵢ) = 100%
2 to 5 slices — however you cut it, the tiling can't leave a gap or an overlap.
Fig. 3. This bar is Ω — every outcome that could happen, drawn once, full width. Drag a gold handle to reweight B₁, B₂, B₃…, or hit + slice / − slice to add or remove a case outright. However you cut it, the twenty dots — the actual outcomes — still land in exactly one color, and Σ P(Bᵢ) locks to 100% every time, because the slices are fractions of the same whole by construction. That's the payoff of chopping Ω up front into pieces that are disjoint (no outcome shared between two slices) and exhaustive (no outcome left outside all of them). The total probability formula then gets to assume every outcome is counted once and only once, before a single number is added.
Now drop your event A across those tiles. A does not respect the boundaries; it cuts through several cases at once. But that is fine, because inside each case the piece of A is easy. It is just P(A|Bᵢ), A's chance in that sub-world, times P(Bᵢ), how much of the whole world that sub-world is. Add up the weighted pieces and you have rebuilt all of A: P(A) = Σ P(A|Bᵢ)·P(Bᵢ). This is the law of total probability. The cleanest way to feel it is as a tree. Branch first on which case you are in, then on whether A happens, and read the answer off the leaves.
P(red) = 0.30 — sum of both greens
multiply DOWN each branch; add ACROSS the green (A) leaves
Fig. 4. First you land in a case — Urn 1 with probability P(Urn1), or Urn 2 with probability P(Urn2) (the two must add to 1 — that's what makes them a full partition). Only then does A (drawing red) get decided, with its own odds P(A|Bᵢ) inside that case. Drag any slider: the line for each branch gets thicker or thinner as its probability changes, each green leaf recomputes as P(Bᵢ)×P(A|Bᵢ) — multiplying down the path — and the two green (A) leaves add straight into P(A) at the top. That's why total probability works: multiplication runs down each branch, and axiom 3 — disjoint pieces add — runs across the leaves.
Every path down the tree multiplies, because it is the multiplication law from §1 applied one branch after another. And the A-leaves add, because they are disjoint — axiom 3 from Chapter 3, where disjoint things sum. That is the whole mechanism: multiply along, add across. There is a second way to see the exact same sum, as a stacked bar. Each case contributes a block of height P(A|Bᵢ)·P(Bᵢ), and the blocks stack up to the total P(A). Slide the case weights below and watch the tree-leaves and the bar-blocks move in lockstep. Same truth, two pictures.
tree Σ 0.064 = bar top 0.064
aha: the tree's three weighted leaves are literally the same three numbers as the bar's three blocks — just arranged two ways.
Fig. 5. Three cases B1/B2/B3 share the day's output (drag the weights, or hit a preset) and each has its own fixed defect rate. In the tree, each leaf's height is the weighted contribution P(Bi)×P(A|Bi) — the exact same three numbers that, on the right, stack into one bar reaching P(A). Slide any weight and watch both panels move together: the tree's leaves and the bar's blocks are never just similar — they're the identical weighted sum, drawn two ways. That's why a tree and a bar for the same problem always agree.
Now the load-bearing caveat, and the fastest way to learn it is to break the rule and watch the damage. Total probability only works because the cases are disjoint, with each outcome counted once. Let the cases overlap, so some outcomes belong to two cases at once, and you count their shared region twice. The pieces then overshoot P(A). If you are summing a full partition, the total sails straight past 1, which is nonsense for a probability. Drag the cases into each other below and watch the sum inflate.
clean partition — Σ matches P(A)
That's why disjointness isn't fine print — overlap and you charge some outcomes twice, and a probability sails past 1.
Fig. 6. Two cases split the year cleanly: B1 — train days, B2 — bus days — each day exactly one, so P(A∩B1)+P(A∩B2) lands right on the true P(A)=0.55. Now drag B2 left, into B1's territory: the shared days flag red — they're logged under both cases — and the Σ meter climbs past its own true value, then past the ceiling of 1.00 itself. Disjointness wasn't fine print: it's the only thing stopping a sum-of-cases from double-billing the outcomes they share.
You have watched a partition work, then watched it fail when the cases overlap. But every example so far handed you the cases ready-made. On a fresh problem, choosing the Bᵢ yourself is the real skill: split the world so that nothing is left out and nothing is shared. A partition is not given to you. It is something you build and then check with two questions.
switch cases on — each one claims its faces
gaps 4 · shared 0
a valid split passes both lights: nothing left out, nothing counted twice.
Fig. 7. A partition is a claim you verify, not a gift. Switch cases on — low, mid, high, even, odd, prime — and each one claims its faces on the die. Two lights watch the result: COVER goes green only when no face is left in the cold (it flags orphans as hollow red), and DISJOINT goes green only when no face is claimed twice (it flags a shared face solid red with the count). Start from low+mid and four faces sit uncovered; add high and both lights turn green, so Σ P(Bᵢ) = 12/12 = 1 unlocks. Hit try a trap: it drops in even+odd+prime — every face covered, yet 2, 3, 5, 7, 11 are counted twice, so the sum stays locked until you drop prime. The aha: “partition” stops being a word and becomes two checks you can run on any problem — nothing left out, nothing counted twice — before a single weighted piece is added.
So "disjoint and exhaustive" is not textbook fine print. It is the thing that makes the sum honest. Partition cleanly and every outcome pays into exactly one bucket. Overlap and you charge some outcomes twice. With the rule respected, total probability turns a hard question into a walk through easy sub-worlds. Let's prove it does real work by running it on an actual factory floor — two machines, two defect rates, one overall shipment — and you predict the blended rate before the code does.
predict: the blended defect rate?
pick a guess, then ship the batch
A is 70% of the shipment at 2% defective; B is 30% at 8% — not a 50/50 mix.
Fig. 8. Factory A ships 70% of the batch at a 2% defect rate; factory B ships the other 30% at 8%. Pick a guess, then run 8,000 units through the loop — no formula anywhere in it, just a weighted coin-flip for which factory shipped each unit, then another for whether it's defective. Watch the blue running rate settle on the gold line at 3.8%, not the orange 5% "average of the two rates" — because A made most of the shipment, its low rate pulls the blend down toward it. That's why the overall rate is Σ P(defect|i)·P(i): each factory's rate weighted by how much of the shipment it made, never a plain average.
There it is, executed and confirmed. The overall defect rate is not the average of the two machine rates. It is the weighted average, with each machine's rate scaled by how much of the shipment that machine made. That weighting is total probability doing its job, and the same weighted sum is about to reappear as the most important denominator in the course. Because now we have both pieces, the multiplication law and total probability, and we can finally perform the flip.
03The flip
Let's name the asymmetry that makes Bayes necessary, because it is the permanent orienting question of all inference: what can you measure, versus what do you want? One direction is almost always the easy one to get. You find P(positive | sick), the test's hit rate, by handing the test to known-sick patients and counting. That is the forward arrow, cause to effect. But the arrow you need when your own result comes back points backward: P(sick | positive), effect to cause. You have got the world in your hand facing the wrong way. Look at the two arrows side by side.
flip the arrow
the lab's arrow — easy to measure
That's why inference needs a tool at all — the arrow you can measure points the opposite way from the one you want.
Fig. 9. Same test, two different arrows. Forward is the one a lab can hand you straight from the data: take a group of known-sick patients, test them, and P(positive | sick) comes out to 99% — no inference needed, just counting. Backward is the one you actually stand in as a patient: you're handed a positive result and want P(sick | positive) — and because the disease is rare (1%), that number collapses to roughly 17%, even with a 99%-sensitive test. The arrow you can measure points the opposite way from the one you need — which is exactly why the rest of this chapter exists.
Fig. 9 named the two arrows for one test. But the mistake that sinks people is not the algebra. It is grabbing the wrong arrow without noticing. Every problem hands you one conditional and asks for its reverse. So the first move, before any formula, is to sort what you can measure from what you want. Then name the hypothesis and the evidence out loud.
Sort the arrow, then tag H and E — six real statements, three matching pairs
tap the words that are H, then the words that are E
which arrow is this?
tag H, tag E, then sort the arrow
Every Bayes problem is one shape: which arrow do you hold?
FORWARD — P(E|H): the lab's easy arrow, the one you're handed
BACKWARD — P(H|E): the one you actually want, needs Bayes to flip
Naming H (cause) and E (effect) first turns the flip into a mechanical step — no algebra needed, just sorting.
Fig. 10. Six real statements, three matching pairs. Tag the words that are H (the cause) and E (the evidence), then sort each one FORWARD — P(E|H) — or BACKWARD — P(H|E). Check reveals the true arrow and colours your taps green or red; a wrong sort snaps the arrow back to its true direction and your streak resets. Solve both halves of a pair and the widget marks it matched: forward and backward were never two different facts, just one P(H∩E) read in two directions. No algebra here — sorting the arrow and naming H and E is the whole hard part.
Here is the whole theorem in one move, and it is the payoff of §1, so watch closely. We showed the overlap can be peeled two ways: P(A∩B) = P(A|B)·P(B) and also P(A∩B) = P(B|A)·P(A). Take one rectangle of area P(A∩B) and peel it along both grains, first as a tall-thin cut, then as a short-wide cut. See with your own eyes that the two cuts give the same area.
P(B) chance of B · P(A|B) chance of A once B has happened · P(A∩B) both together.
tall‑thin: P(A|B)·P(B) = 0.30
Peel this one overlap two ways — the areas can’t disagree.
Fig. 11. One rectangle of overlap — the area P(A∩B) = 0.30 — peeled along both grains. Slice it by B first and it reads P(A|B)·P(B); slice it by A first and it reads P(B|A)·P(A). Drag the block tall‑thin then short‑wide: the shape changes, the area never does. Hit Set equal and the two products sit side by side at the same 0.30 — forced to be equal. Divide by P(B) and you have Bayes. That’s the whole theorem: not a new axiom, just one overlap counted two ways.
Because both products equal the identical overlap, they equal each other: P(B|A)·P(A) = P(A|B)·P(B). Now the arrow you could not measure is trapped on the left, everything you can measure is on the right, and one division sets it free. Divide both sides by P(A) and you have it: P(B|A) = P(A|B)·P(B) / P(A). That is Bayes' theorem, the flip made permanent. Step through the three honest lines and watch the backward arrow fall out of the forward one.
STEP 1 / 3
two peelings of one overlap
same rectangle, sliced two ways
Fig. 12. The same violet rectangle A∩B, cut two ways: restrict to B then slice the A-fraction inside it (blue, P(A|B)·P(B)), or restrict to A then slice the B-fraction inside that (gold, P(B|A)·P(A)). Step through: both cuts measure the same area, so the two products are equal — and dividing that equation by P(A) traps the unmeasurable backward arrow P(B|A) alone on the left, with everything you can actually measure pushed to the right. No new axiom, no memorizing — just the overlap read twice.
Sit with how little happened there. There was no new axiom, no leap of faith, and no memorization required. Just "the overlap does not care about order," written twice and divided once. If you ever forget the formula, you can re-derive it in ten seconds from that single symmetry. That is the difference between owning an idea and renting it. Now let's give the four pieces their real names, because those names are the vocabulary of every inference system on Earth.
04Bayes in full: the denominator is the evidence
Rewrite the flip with the roles filled in. Let H be a hypothesis (you're sick) and E the evidence (you tested positive). Then P(H|E) = P(E|H)·P(H) / P(E), and each term is a character in the story. P(H) is the prior, what you believed before the test. P(E|H) is the likelihood, how well the hypothesis predicts the data. Their product, divided by P(E) the evidence, gives P(H|E), the posterior, your updated belief. Hover each term below and watch it light up in both the formula and the plain-English sentence.
hover or click a term
— hover a term —
Four names for the four roles in every Bayes update.
Fig. 13. The same four pieces, colour-bonded: P(H) the prior (what you thought), P(E|H) the likelihood (what the data says), P(E) the evidence (every way the data could show up), and P(H|E) the posterior (what you think now). Hover or click any term and it lights up in the fraction, the flow diagram below, and its own plain-English line — that's why one formula reads as belief-updating: a prior, corrected by data, becomes a posterior.
Now the connection that ties this whole chapter into one knot, and it is why we built total probability first. That denominator, P(E), the "evidence," looks like the easiest term, but it is the one everyone fumbles. What is the plain probability of testing positive? You cannot read it off a spec sheet, because a positive can arrive two ways: from a sick person as a true positive, or from a healthy person as a false positive. So you compute it by total probability, summing over both worlds: P(E) = P(E|H)·P(H) + P(E|Hᶜ)·P(Hᶜ). The denominator is the weighted sum from §2. Watch the full two-branch tree assemble, with the evidence pooling at the bottom.
P(H|E) = 16.7% · P(E) = 0.0594
Fig. 14. The same test on a two-branch tree. The top branch is the sick minority; the bottom is the whole healthy crowd. Each branch reaches a positive test — the sick with probability P(E|H) (sensitivity), the healthy with probability P(E|Hᶜ) = 1−specificity (the false-positive rate). Their two products pool into the bar at the bottom: that pool is P(E), Bayes' denominator — the total chance of a positive, summed over every world it could have come from. It opens with a 99%-sensitive test that is right only 17% of the time, because the denominator counts the entire healthy crowd's false positives right alongside the true ones — drag the prior down and watch the gold false-positive slice swallow the bar even further.
That denominator is where the drama lives. It counts every way the evidence could appear. When the healthy population is enormous and the sick one tiny, the false positives in that sum can drown out the true ones. Let's feel it with clean numbers, stated once and for real: a disease with prevalence 1 in 1000, which is 0.1%, and a test that is 99% accurate both ways. You test positive. Before you reveal it, what does your gut say the chance you are actually sick is? Commit to a guess, then let the flip answer.
guess: ~50% — hit reveal ›
A 99%-accurate test still throws ~10 false alarms for every 1 real case, because sickness is rare — that's why the base rate, not the test's quality, decides the answer.
Fig. 15. Out of 1,000 people at a 0.1% prevalence, only 1 is truly sick — and a 99%-accurate test catches them, giving 1 true positive. But among the 999 healthy people, that same 99% accuracy still misfires on 1% of them: ≈10 false positives. Pick your guess for P(sick | positive), then hit Reveal the crowd: among the 11 people who tested positive, only the 1 gold dot is actually sick — so P(sick | positive) = 1/11 ≈ 9%. The test sounds excellent; the disease is just rare enough to bury its one true signal under ten false alarms. That's the flip total probability forces on you: P(positive) is built mostly out of healthy people's errors, not sick people's true hits — so even after a positive, the odds are still ~10-to-1 that you are healthy.
The real posterior is under 10%. If your gut said "about 99%," you are in excellent company, and you are off by a factor of eleven. The gap opens because the denominator filled with false positives. Out of a thousand people, one is truly sick, but about ten healthy people also test positive, so your one true positive is lost in a crowd of eleven. The test did not lie. The base rate did the damage. That collision between a good test and a rare condition is so important, and so counter-intuitive, that it gets the entire next chapter to itself. For now, hold the shape of it: the flip is honest, but its answer can ambush you. Let's turn to what the flip is really for — not one verdict, but learning.
That crowd of eleven made the answer visible, but the numbers were fixed for you. To own Bayes you need to run the count yourself, on any numbers. So take a room of people, split it by the base rate, apply the two test rates, and read the answer straight off the heads. Set the three knobs, predict the posterior, then watch the people sort themselves into true and false positives.
set numbers, guess, reveal ›
Count people: posterior = green ÷ (green + orange) — true + over all +. No formula.
Fig. 16. The head-count method, turned into a tool you drive. Set N and the three sliders — prevalence, sensitivity, false-positive rate — and watch the crowd split: N into sick vs healthy, each into the four cells. The positive crowd is the ringed top row, true + plus false +. Drag your guess for P(sick | +), then hit Reveal the + crowd and the column lifts out to show the posterior as a real fraction of heads: the default 1% · 99 · 5% reads 99 / (99 + 495) ≈ 16.7%, and the 0.1% · 99 · 1% preset reads 1 / (1 + 10) ≈ 9% — the same numbers you just watched, now in your own hands. Divide the true positives by all the positives and you never need the symbolic formula again: Bayes is just counting.
05The belief-update loop
Here is the reframe that turns Bayes from a formula into a process. Every posterior is a belief you hold after seeing some evidence. So lay the update out as three bars: the prior, what you believed before; the likelihood, what this new data says; and the posterior, what you believe after. The posterior is nothing but the prior reweighted by the likelihood, then renormalized. Drag the prior and the likelihood below and watch the posterior swing between them. It is pulled hard when the data is decisive, and barely nudged when the data is weak.
weak data — posterior barely moved
The posterior is a tug-of-war: prior on one side, likelihood on the other. Near L = 50% the data has no grip and the prior wins outright. Push L toward 0% or 100% and it grips hard — strong enough to drag even a stubborn prior across the 50-50 line.
Fig. 17. Three bars, one rule. Prior is P(H) — how likely you thought the hypothesis was before any data. Likelihood is L — how strongly the data D points that way, on a dial where 50% means the data is equally likely either way (it says nothing), and 0% or 100% means the data is decisive. Posterior — P(H|D) — is what Bayes' rule hands back: L·prior / (L·prior + (1-L)·(1-prior)). Drag the prior and likelihood bars and watch the dashed pull-lines show where the posterior got dragged from. Near the 50-50 line, L has no grip and the prior wins untouched; push L to an extreme and it grips hard enough to flip even a strong prior clean across to the other side.
And now the quietly profound part, the sentence most courses wave straight past and that deserves a monument: today's posterior is tomorrow's prior. Once you have updated on one piece of evidence, that updated belief becomes the starting point for the next piece. So Bayes does not just answer once. It loops. Feed evidence in one observation at a time and your belief marches toward the truth, each step standing on the last. Watch a belief about a coin's hidden bias sharpen with every flip you feed it.
flat prior — you know nothing yet
Shuffle all you like: the dashed target never moves. Order is forgotten — only the tally of H and T decides where belief lands.
Fig. 18. Start flat: with no evidence, every bias p (the coin’s chance of heads) is equally believable. Feed one flip at a time and watch the belief curve get multiplied by that flip’s likelihood — p for a head, 1−p for a tail — then renormalised into a sharper curve. Here is the whole point: that sharper curve is your prior for the next flip. The posterior physically becomes the prior; sequential updating isn’t hand-waving, it’s this array being overwritten in place. And the gold dashed line is where all twelve flips lead — shuffle the deck and it never moves. Feed the flips in any order and belief always lands there, because the endpoint depends only on the total evidence (8 heads, 4 tails), never the order it arrived in.
Notice two things as the belief converges. First, it does not matter what order the evidence arrives in, or whether you swallow it all at once or one bite at a time. The final posterior is the same, because it depends only on the total evidence. Second, a stubborn prior needs a lot of data to move, while an open one snaps into shape fast, which is exactly how it should feel. Let's prove the whole loop actually works by running it: start ignorant about a biased coin, feed it flips, and watch the estimate home in on the true bias.
true bias p — hidden from the updater
— ready to flip —
no flips yet — pure guesswork
more data = more certainty: each flip narrows the band
Fig. 19. Pick the coin's true bias — the number the updater never gets to see — then hit run: each simulated flip nudges the posterior mean (blue) and squeezes its credible band a little tighter around it, chasing the dashed gold truth line. It starts at n=0 owning nothing but "anywhere from 0 to 1"; by flip 40 the band has collapsed to a tight window hugging the real value. That's why more data buys more certainty — every flip is one more update, and though a surprising flip can briefly widen the band, the trend is relentlessly inward.
That marching, self-correcting loop is not a probability curiosity. It has a name and a working implementation, and this is the place to close a loop most courses leave open. The figure below tracks a robot, because a belief that moves is easy to watch: fuse a noisy GPS reading with a noisy wheel-odometry estimate and you are running predict → measure → correct → repeat, which is a prior about the position, a likelihood from the new reading, and a posterior that becomes the next prior. That loop is the Kalman filter, and its beating heart is exactly the Bayes update you just watched. "Sequential updating" is not hand-waving. It is an algorithm you could write today from what this chapter has already given you. See the same three-beat loop, one step at a time.
a robot fusing odometry + GPS, one loop at a time
start — a wide first guess
predict → measure → correct → repeat — the exact loop that steers self-driving cars and spacecraft.
Fig. 20. Step the loop: predict moves the robot's belief forward and lets it spread (odometry drifts); measure brings in a noisy GPS reading; correct fuses the two into a tighter posterior — which becomes next loop's prior. That predict→measure→correct beat, repeated, is sequential Bayesian updating; run on a Gaussian belief, it's exactly the Kalman filter that keeps a self-driving car (or a spacecraft) locked onto where it really is.
06You are here
Let's place what we built on the family tree, because its size is easy to undersell. We did not add a new axiom or a new distribution this chapter. We took Chapter 5's conditioning and learned to read it backwards, and that is the entire content of Bayes. The two enabling ideas, the multiplication law and total probability, were themselves just conditioning rearranged and the measure sliced into disjoint cases. From that one flip falls everything downstream: diagnostic reasoning, spam filters, the Kalman filter, and the whole discipline of statistical inference — learning a model from data, which is the backward arrow run at scale. Find our rung, lit gold.
Hover the spine — the flip lights gold, wired to what it stands on and what it opens.
hover the spine — trace the flip
AHA — conditioning runs cause→effect; the flip runs it backward. Do that backward run at scale on data, and you get the whole back half of the course: learning a model is the flip, repeated.
Fig. 21. The spine so far: sample space → counting → random variables → independence → conditioning — and now the Bayes flip, lit gold, you are here. Hover the figure: the dashed rung brightens to show conditioning is exactly what the flip stands on, and the fan to the right lights up to show what it opens — every chapter of statistical inference still ahead. The flip isn't a new object; it's Chapter 5's conditioning, read backward, and that backward read is the hinge the rest of the course swings on.
And here is the seam into the next chapter, which is really just this one turned up to its most alarming setting. We got a preview with the 99%-test-1-in-1000-disease shock. The flip is a faithful machine, but hand it a tiny prior and the answer stops matching anyone's intuition. The denominator — the evidence, the total-probability sum — fills up with a crowd of false positives from the vast healthy majority, and they swamp the handful of true ones. Same formula, no new maths, an extreme regime. In Chapter 7 we walk into that regime deliberately, make the crowd of false positives visible as a field of dots, and watch a "very accurate" test turn out to be nearly useless: the base-rate trap. Watch the prior shrink and the trap yawn open.
eroding — false positives closing in
Same test, same 99% sensitivity, same 5% false-positive rate — only the prior shrank. That's the whole trick Chapter 7 runs: no new maths, just this dial pushed toward zero until the false-positive crowd swamps the true positives.
Fig. 22. Twenty people just tested positive on a test that's 99% sensitive with a 5% false-positive rate — the same numbers the chapter opened with. Drag the handle (or the slider) and the prior — P(sick), what you believed before any test — slides on a log scale from 50% down to 0.01%. The dot-crowd recomputes live via the same Bayes formula: at the chapter's own 1% base rate, about 3 of the 20 dots are genuinely sick (posterior ≈ 17%); drag toward the extreme and that count collapses to zero — the false-positive crowd owns every dot. Nothing about the test changed. That's why Chapter 7 needs no new maths — a tiny prior alone is enough to turn a 99%-sensitive test into a near-useless one.
Sliding one prior showed the trap widening. But the sharpest lesson hides in a comparison: run the very same test in two different rooms. In a clinic full of likely-sick patients, a positive nearly convicts. In a general screen of mostly-healthy people, the identical positive barely moves the needle. Give both rooms a positive, predict each verdict, and feel why the first question is always this: which population am I standing in?
guess clinic 50% · screen 50% — reveal ›
Same person, same test, same positive — only the room changed. A result carries no fixed meaning until you ask which population you're standing in.
Fig. 23. One test, locked once: 99% sensitivity, 5% false-positive rate — identical on both sides. Drag each panel's handle to predict P(sick | positive) for that room, then hit Reveal both: at the defaults, the Symptomatic clinic's 17.0% prior turns a positive into ≈80.2% likely sick, while the Population screen's 0.50% prior turns the same kind of positive into only ≈9.0% — both natural-frequency crowds fill in gold-green (truly sick) and red (false alarm) so you can count it, not just read it. Hit Swap the patient and watch one positive person physically move from one crowd to the other: nothing about them or the test changed, only the room. That's the reflex to build — before trusting any positive, ask which population am I in?
The machine is built, and it runs both directions now: cause to effect, and effect back to cause. What is left is to feel how violently it can defy intuition when the base rate is small, and to build the picture that makes the honest answer believable. That is the trap, and it is where we go next. Turn the page.