Probability as Calibrated Belief

By the end of this lesson, you will be able to...

• Turn a vague statement such as “low risk” into a defined event, a probability range, and an update trigger.

• Distinguish the probability of an event from your confidence in the estimate.

• Use a small calculation and a reference class without treating either one as a guarantee.

Idea in one sentence: A decision probability is a measured expression of belief about a defined event, useful only when its assumptions, uncertainty, and update conditions are visible.

Core Insight

Consider the checkout team from the previous lesson. It has five options for the next campaign. One option combines a failure replay with a small canary. The team must decide whether the residual risk is acceptable.

An engineer says:

The chance of another outage is low.

The product manager hears 5%. The incident lead hears 20%. The finance lead hears “not zero, but not worth discussing.” They are using the same words for different beliefs.

The team needs a more precise question:

What event are we estimating, over what time, under which option, and what evidence would make us change the estimate?

Probability does not remove uncertainty. It gives uncertainty a shape that people can inspect, compare, and update.

The Vague Forecast

“Likely,” “unlikely,” and “safe” are useful conversational shortcuts. They become dangerous when a decision depends on them and nobody knows what they mean.

The first repair is to define the event.

For the checkout campaign, let E be:

During the first 24 hours of the campaign, checkout errors exceed 1% for at least five minutes because a zone loss causes the cache and its fallback path to overload.

This definition fixes several things:

• the time window: first 24 hours;
• the threshold: errors above 1% for five minutes;
• the mechanism: zone loss followed by overload;
• the affected promise: checkout availability;
• the option: the estimate belongs to one design, not to “the system” in general.

Without these boundaries, two people can disagree while both believe they are being precise.

Plain meaning:

A probability is a way to say how strongly we expect a defined event to happen.

In this scenario:

“I estimate a 25% chance that event E occurs during the campaign under the warm-failover option.”

Technical name:

This is a calibrated belief: a probability stated clearly enough that later evidence can show whether the forecast was well aligned with reality.

Start With a Reference Class

The team looks for comparable evidence instead of inventing a number from feeling.

During the last twelve high-traffic campaign days, one day had more than five minutes of checkout degradation after an infrastructure failure. A simple reference rate is:

1 affected day / 12 comparable days = about 8%

That 8% is not automatically the new forecast. The current situation differs:

• traffic is expected to be higher;
• the failover path is new;
• the team has not yet replayed a zone loss with campaign traffic;
• the proposed option removes some duplicate cache work.

The team therefore records a range rather than pretending that the old rate is destiny:

The estimate is not “25% true.” It is a current belief supported by a small reference class and adjusted for known differences.

Probability Is Not Confidence in the Estimate

Two statements can sit next to each other:

1. “There is a 25% chance of event E.”
2. “I have low confidence that 25% is the right number.”

The first describes the event. The second describes the quality of the estimate.

This distinction matters when evidence is sparse. A team may need to act on a 25% estimate while admitting that the range could be wide. Hiding that weakness behind a crisp number makes the decision look more certain than it is.

Do not replace the number with a vague adjective. Replace false precision with a number plus its limits:

I currently estimate 20-35%, centered near 25%. This is low-confidence because we have only twelve comparable days and no direct failover replay.

That sentence gives the next lesson something to work with. It also tells the team what information is worth buying.

A Worked Forecast Update

The team runs a controlled replay of campaign traffic with one zone removed.

The first replay produces three failures in ten runs. The test is not a perfect copy of production, but it is directly connected to event E. The team updates its record:

The number moved because evidence changed, not because a leader became more persuasive.

Now suppose a warm-failover change is added and the same replay produces zero threshold breaches in twenty runs. The team should lower its estimate for that option, but not set it to zero. The test may miss a correlated dependency, and twenty runs are not the whole future.

The update is a disciplined change of belief:

old estimate -> new evidence -> revised estimate -> changed action or next test

Check: A manager says, “The replay had no failures, so the probability is now 0%.” What is missing?

Think first, then reveal.

Answer: A test can reduce belief in the event without eliminating it. The team must ask how representative the replay was, what it did not exercise, and which remaining dependencies could fail.

A Small Calculation With a Large Warning

Suppose the team estimates a 25% chance of event E on each of four campaign days. If the days were independent, the chance of at least one event would be:

1 - (1 - 0.25)^4
= 1 - 0.75^4
≈ 68%

This is a useful calculation, but it is not automatically a production forecast. A single regional provider problem could affect all four days, making the events correlated. If the days share the same hidden condition, multiplying independent daily chances is misleading.

The calculation teaches two habits:

• define what probability refers to;
• inspect the dependence assumptions before extending it across time.

Probability gives a model a shape. It does not make the model true by itself.

Calibration Over Many Forecasts

Calibration is easier to see across a collection of predictions than in one event.

If a team makes twenty forecasts at 70% and the events happen in roughly fourteen of those cases, its forecasts are behaving in a calibrated way. One 70% forecast can still fail. A failure does not automatically prove that the estimate was irrational.

Calibration also exposes overconfidence. If forecasts marked 90% happen only half the time, the team is using certainty language as decoration.

The team should keep a simple record:

The record is not a scoreboard for personal virtue. It is feedback for the forecasting process.

What This Changes

Before this lesson, the team might ask:

Is the warm-failover option safe?

After this lesson, it can ask:

What event are we forecasting, with what probability range, based on which reference class, and what observation would update the estimate?

That question improves the next decision in three ways:

1. It reveals which evidence is missing.
2. It lets different options be compared on the same event definition.
3. It creates a trigger for changing course instead of waiting for a postmortem.

The estimate still does not choose the option. A 20% risk may be acceptable for a reversible experiment and unacceptable for a payment-data migration. The next lesson adds the values and stakes needed for that comparison.

Check: Which forecast is easier to review later?

• A. “The migration is probably safe.”
• B. “There is a 20-35% chance that recovery exceeds 30 minutes during a regional outage in the first month; confidence is low because no regional replay exists.”

Think first, then reveal.

Answer: B. It defines the event, gives a range, states the confidence in the estimate, and names the missing evidence.

Trade-offs and Limits

The central trade-off is between useful precision and false precision. A number can make disagreement actionable, but a narrow number can hide weak evidence and create an illusion of control.

Probability work also costs time. Building a reference class, defining events, running tests, and tracking forecasts may be too expensive for a cheap reversible decision. The effort should match the stakes and the cost of being wrong.

Probability does not settle values. It cannot tell the team whether a 25% outage risk is worth €40,000, lost trust, or a two-week delay. It also does not guarantee that the event definition captured every harm. Those are boundaries for later decision work.

Watch for three signals that the model is failing:

• people use the same percentage for different events;
• the range never changes after new evidence;
• high-confidence forecasts repeatedly fail without any calibration review.

The right response is not to ban numbers. It is to repair the event definition, assumptions, reference class, or update rule.

Common Confusions

Confusion: A 70% probability means the event must happen

Why it is tempting: a high number sounds like a promise.

Better model: 70% expresses belief before the event. The event can fail to happen, and the forecast can still have been reasonable.

Confusion: Confidence and probability are the same number

Why it is tempting: both use percentages in ordinary conversation.

Better model: probability describes the event; confidence describes how much trust to place in the estimate itself.

Confusion: A reference rate is the answer

Why it is tempting: historical counts feel objective.

Better model: a reference class is a starting point. Current conditions may differ in traffic, mechanism, incentives, or dependencies.

Confusion: More decimal places mean more knowledge

Why it is tempting: 27.4% looks more rigorous than “about one in four.”

Better model: precision should match evidence. Sparse data usually supports a range and an update trigger better than extra decimals.

Practice: Forecast a Migration Risk

Return to the event-store migration from the previous lesson. The cheaper provider has unknown regional recovery behavior, and the team has six weeks.

Write a forecast card with:

1. one precisely defined failure event;
2. a reference class or explicit reason no useful reference class exists;
3. a probability range and a central estimate;
4. confidence in that estimate;
5. two pieces of evidence that would move the estimate up or down;
6. one calculation whose assumptions you state clearly.

A good answer should not use a number as decoration. It should explain what the number refers to, why the range is wide or narrow, and what the team will do when new evidence arrives.

Connection to the Next Lesson

Once the team has probabilities, it still has not answered what matters most. The next lesson, Values, Utilities, and What Matters, shows how stakes, values, and constraints change the choice even when two people agree about the facts.

Resources

• [BOOK] Thinking, Fast and Slow — Focus: overconfidence, anchoring, and the limits of intuitive probability judgments.
• [BOOK] How to Decide — Focus: using explicit probabilities, decision trees, and update rules without confusing estimates with certainty.
• [ARTICLE] Stanford Encyclopedia of Philosophy: Decision Theory — Focus: how acts, uncertain states, outcomes, and preferences fit into a formal decision model.

Key Takeaways

• Define the event before assigning its probability: time, threshold, mechanism, and option all matter.
• A probability estimate and confidence in that estimate are different statements.
• Reference classes, small calculations, and tests support belief, but each depends on assumptions that must remain visible.
• Calibration is learned across many forecasts, not proved by one success or failure.
• The central trade-off is useful precision versus false precision; every serious estimate needs a range, a boundary, and an update trigger.