Probability is the product

The idea in one line: A probability says how often answers like this one turn out true, and that lets you price a decision, pick a threshold and automate safely, which a bare “yes” or “no” never can.

A model that says “this build will pass” gives you a guess. A model that says “pass, 0.97” gives you something you can do arithmetic with: how much an automatic merge will cost on average, how many cases to send to a human, and where to draw the line when the cost of a mistake changes. The course’s research notes put the whole value of a decision model in one sentence: a probability plus a threshold plus a fallback is the architecture.

The 10x is in automation. Say a small model costs 1 unit per case and a big one costs 100. The small model reads every case and sends only the ones it is unsure about to the big one. If it keeps 80% of cases, you pay 1 + 0.2 × 100 = 21 units instead of 100: a 4.8x saving. Keep 95% and it is 16.7x; keep 99% and it is 50x. That arithmetic is from the course’s calibration research notes, and it only works if the model’s “I’m sure” means what it says. This lesson builds that skill from scratch.

A probability is a number from 0 to 1 that says how often something happens in the long run, among cases like this one. 0 means never, 1 means always, 0.3 means about 3 times in 10.

A weather forecaster who says “30% chance of rain” on 100 different days is doing a good job if it rains on about 30 of them. That property has a name, calibration, and it gets its own lesson: calibration.

You can measure a probability by counting. Fedora’s build system, Koji, ran 5,774,084 successful and 284,204 failed per-architecture build tasks in the 12 months to 2026-10-28, by the research notes’ own count from Koji’s public records. So the chance that a random task fails is:

284,204 / (5,774,084 + 284,204) = 284,204 / 6,058,288 ≈ 0.047

About 4.7%, or about 780 failures a day. A probability you get by counting like this, before you know anything about a particular build, is called the base rate.

A probability distribution gives a probability to every possible answer, and those probabilities add up to 1.

A real one: in Fedora’s GCC 15 test rebuild, 1,438 of 8,711 builds failed, and maintainers sorted 914 of the failures by cause by hand (Fedora wiki: F42 GCC 15 mass prebuild, updated 2025-01-10):

That table is exactly the shape of answer a decision model gives you for a question like “which failure class explains this log?”. Jev, the course’s reference product, returns a distribution like this for each question you ask. In its documentation’s quick-start example, a “frustration” question with three levels comes back as 0.33, 0.67 and 0.0 (TypeSafe docs: Quick start, read 2026-10-28). You will meet that response format properly in the anatomy of Jev.

The expected value of a numbered outcome is the average you would get over many repeats: each value times its probability, all added up. Jev’s quick-start “frustration” levels are numbered 0, 1 and 2, so its expected level is:

0 × 0.33 + 1 × 0.67 + 2 × 0.0 = 0.67

That 0.67 is exactly the score Jev returns for that question. The expected value is useful because it can land between levels and still mean something: “mostly level 1, a little towards calm”.

A conditional probability, written P(A | B), is the probability of A among only the cases where B is true. Read the bar as “given”.

The same question, “will this build fail?”, has different answers under different conditions. All of these come from the research notes’ counts and sources:

A model’s output is always a conditional probability: P(answer | everything in the input). The input is the condition. The better the model reads the input, the further it can move away from the base rate when the evidence says so.

Bayes’ rule tells you how to update a probability when you see new evidence. It sounds abstract. With counts it is just careful bookkeeping.

The question: will this package build pass? Suppose you notice the update bumps a dependency to a new major version. How worried should you be?

You need three numbers. The first is real; the other two are invented for this exercise:

• Base rate: about 5% of builds fail (rounded from Koji’s 4.7%).
• Among failing builds, 60% involved a major-version bump (made-up).
• Among passing builds, 10% involved a major-version bump (made-up).

Now imagine 1,000 builds:

                1,000 builds
               /            \
        50 fail              950 pass
       /       \            /        \
  30 bumped  20 not    95 bumped   855 not

• 60% of the 50 failures is 30 builds that failed and had a bump.
• 10% of the 950 passes is 95 builds that passed and had a bump.
• So 30 + 95 = 125 builds had a bump, and 30 of those failed.

P(fail | bump) = 30 / 125 = 0.24

The bump took you from 5% to 24%. It is a strong warning sign, six times more common in failures than in passes, and the chance of failure is still under one in four, because failures are rare to begin with. Forgetting the base rate is the most common mistake people make with evidence.

The same arithmetic as a formula:

P(fail | bump) = P(bump | fail) × P(fail) / P(bump)
               = 0.6 × 0.05 / 0.125 = 0.24

P(fail) is called the prior (what you believed before the evidence), and P(fail | bump) the posterior (what you believe after).

There is a faster way that experts use. Odds are “for : against”. A 5% chance is odds of 5 : 95, or 1 : 19. The evidence is 6 times likelier in failures (0.6 / 0.1), a number called the likelihood ratio. Multiply:

prior odds 1 : 19   ×   6   =   posterior odds 6 : 19
P(fail) = 6 / (6 + 19) = 0.24

Now move the base rate. During the GCC 15 test rebuild, the base rate was 16.5%, odds of about 0.198. Times 6 gives about 1.19, so P(fail) ≈ 1.19 / 2.19 ≈ 0.54. Same evidence, same model of it, but a compiler-bump week turns a 24% risk into a 54% risk.

This is why calibrated probabilities are so useful: they compose. You can fold in a new base rate with one multiplication, without retraining anything.

A probability alone does not tell you what to do. You also need what each mistake costs. Expected cost is each outcome’s cost times its probability, added up. You pick the action with the lowest expected cost.

The calibration research notes work through this with a bootc distro image and invented, illustrative costs. A model gives p = P(this dependency bump builds and boots):

• Merging a bad bump costs $400 (a broken nightly image, an hour of debugging).
• Rejecting a good bump costs $40 (redo it later, a delayed security fix).
• Sending it to a human reviewer costs $20 (assume the human is always right).

The expected cost of each action:

merge:   400 × (1 − p)     you pay only if the bump was bad
reject:   40 × p           you pay only if the bump was good
review:   20               you always pay the reviewer

Solve for where the lines cross and you get a policy: auto-merge above 0.95, auto-reject below 0.50, send the middle to a human. (Merge beats review when 400 × (1 − p) ≤ 20, so p ≥ 0.95. Reject beats review when 40 × p ≤ 20, so p ≤ 0.50.)

With only two actions, merge or reject, the break-even threshold is p ≥ C_FP / (C_FP + C_FN) = 400 / 440 ≈ 0.91, where C_FP is the cost of a false positive (merging a bad bump) and C_FN the cost of a false negative (rejecting a good one). That rule is from a classic paper on cost-sensitive learning, which also shows that moving the threshold is the principled response when costs change (Elkan, IJCAI, 2001).

Here is the whole lesson so far in code you can run:

# Bayes with counts, then the cheapest action (toy costs from the text).
def posterior(prior_fail, p_signal_if_fail, p_signal_if_pass):
    """P(fail | signal) by Bayes' rule."""
    fail = prior_fail * p_signal_if_fail          # fail AND signal
    ok = (1 - prior_fail) * p_signal_if_pass      # pass AND signal
    return fail / (fail + ok)

print(round(posterior(0.05, 0.6, 0.1), 2))    # 0.24, a normal week
print(round(posterior(0.165, 0.6, 0.1), 2))   # 0.54, compiler-bump week

def best_action(p_good, bad_merge=400, good_reject=40, review=20):
    """Cheapest action for a bump that is good with probability p_good."""
    costs = {"merge": bad_merge * (1 - p_good),
             "reject": good_reject * p_good,
             "review": review}
    return min(costs, key=costs.get)

print(best_action(0.97), best_action(0.80), best_action(0.30))
# merge review reject

A bare label (“pass”) is a probability with the threshold already chosen for you, usually at 0.5, and then thrown away. Here is what you lose (the list follows the calibration research notes):

1. Costs change, and a probability lets the threshold follow. In a week with an urgent security patch, rejecting a good bump costs more. Recompute the threshold; no retraining. A label hard-codes one threshold.
2. Accuracy at 0.5 is the wrong score. With these costs the break-even point is about 0.91, so “accuracy” measured at 0.5 says little about money.
3. Triage. Probabilities rank the review queue, and you can predict how many cases land in the middle band, so you can staff for it.
4. Composition. Probabilities multiply through a pipeline and absorb new base rates, as the odds shortcut showed. Labels cannot.
5. Auditability. “We automated everything above 0.95 and saw 2.1% errors against 3% predicted” is a contract you can test. “The model said yes” is not.

There is a catch, and it is the most expensive mistake in this whole field. The probability has to be honest. Suppose the model says 0.97, but bumps at that score actually succeed only 90% of the time. Then each auto-merge costs 400 × 0.10 = $40, twice the $20 review. With honest 0.97s, each costs $12, a saving of $8 per item. Same accuracy, same ranking of cases, opposite business result.

How do you tell whether a model’s probabilities are honest? You score them after the outcome is known.

A scoring rule gives a forecast a number once you know what happened. Two matter:

Brier score = (p − y)²          y = 1 if it happened, else 0
log loss    = −ln(p given to what actually happened)

Lower is better for both. Worked example, a model that said “pass, 0.9”:

A shrug, 0.5 every time, scores (0.5 − y)² = 0.25 Brier whatever happens. Log loss punishes confident mistakes hard: putting 0.0001 on what actually happened costs −ln 0.0001 ≈ 9.2.

Both rules are proper: you get the best expected score only by reporting what you truly believe (Gneiting & Raftery, JASA, 2007). Check it by hand. Say you truly believe a build passes 70% of the time. Your expected Brier score if you report q:

report 0.7:  0.7 × (1 − 0.7)² + 0.3 × 0.7² = 0.063 + 0.147 = 0.21
report 1.0:  0.7 × 0          + 0.3 × 1.0² = 0.30
report 0.5:  0.7 × 0.25       + 0.3 × 0.25 = 0.25

Honesty wins. That is why proper scoring rules are used as training losses, as rewards and as the fair way to compare vendors: no model can game them by sounding more or less sure than it is.

As of October 2026, from the research notes:

• Pre-trained models start honest; later training can break it. GPT-4’s base model had an expected calibration error (ECE, the average gap between stated confidence and actual accuracy) of 0.007 on an MMLU subset. After reinforcement learning from human feedback it was 0.074, about 10 times worse (GPT-4 Technical Report, 2023-03-15).
• Putting a proper scoring rule into training fixes it. RLCR adds a Brier term to a reinforcement-learning reward. It took Qwen2.5-7B on HotpotQA from ECE 0.37 under ordinary RL to 0.03, at the same 62-63% accuracy (Damani et al., 2025-07-22). TypeSafe says Jev’s training, “Reinforcement Learning for Calibrated Decisions”, follows this direction, but it has published no paper and no calibration numbers. That is TypeSafe’s claim, not a measurement.
• Independent tests of Jev are mixed. Vals AI measured ECE 0.011 on one claim-checking task and 0.108 on a LegalBench slice (Vals AI, 2026-10-06). The community Decision Index puts Jev 1.14 at 0.080 overall (Decision Index data, generated 2026-10-28).
• Confidence is not probability. Jev returns a confidence field next to its probabilities, but it is a fixed formula of the distribution’s spread, not the chance the answer is right. For Choice it is (p_max − 1/n) / (1 − 1/n) (TypeSafe docs: Confidence, read 2026-10-28). Use the probabilities for arithmetic.

Open problems:

• Honesty can break when the wording changes. Arize reversed a hallucination-detection question. Jev, Cloudflare’s Clef and OpenAI’s decision endpoint kept their ROC AUC (a 0-to-1 measure of how well a model ranks true cases above false ones, where 0.5 is guessing) at 0.89-0.93. Liquid d1 dropped to 0.17, worse than guessing (Arize, 2026-10-07). A model that is good on one phrasing may not be on another.
• Measuring honesty needs labels. A perfectly calibrated model still scores an ECE of about 0.03 on 1,000 examples from noise alone, by the research notes’ own simulation. Small test sets cannot tell good from great.

The rest of the story, from measuring calibration to fixing it, is in calibration, and turning probabilities into a running automation policy is in from probability to automation.

• Strictly Proper Scoring Rules, Prediction, and Estimation (Gneiting & Raftery, 2007): the reference on why honest forecasts score best.
• The Foundations of Cost-Sensitive Learning (Elkan, 2001): the threshold rule from a cost matrix, in a few pages.
• Language Models (Mostly) Know What They Know (Kadavath et al., 2022): when language models’ probabilities are calibrated, and when they stop being.
• Beyond Binary Rewards (RLCR) (Damani et al., 2025): a proper scoring rule as a training reward, with the proof.
• Selective Classification for Deep Neural Networks (Geifman & El-Yaniv, 2017): the “answer only when sure” idea that turns probabilities into automation.