Review: From Sample Spaces to Conditional Models

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

• Audit a probability model from its boundary and outcomes through its summaries and dependence assumptions.

• Separate an expectation, a conditional probability, and an empirical simulation frequency.

• Repair a flawed reliability claim and state what evidence the model still needs.

Idea in one sentence: A useful uncertainty model is a chain of explicit choices, and a mistake in an early link can make every later calculation answer the wrong question.

Core Insight

Consider the notification client used throughout the first five lessons. It sends one attempt, waits two seconds, and retries once after a timeout. An operations note says:

“The client succeeds 96% of the time, needs 1.2 attempts on average, and two timeouts happen only 4% of the time. We can promise reliability and budget exactly 1.2 attempts per request.”

The note contains familiar numbers, but it combines several different claims. Before accepting it, audit the model in order:

1. What is one run, and where does it start and stop?
2. Which complete outcomes are possible?
3. Which random variables answer the operational questions?
4. Which probabilities describe the outcomes?
5. What does the average summarize?
6. Are repeated observations independent, or do they share a cause?
7. Does a simulation agree with the stated rules?

This is the first review checkpoint. It does not add a new probability object. It tests whether the objects already introduced still fit together.

The Model Card

Use a compact model card to keep the chain visible.

The card is not paperwork for its own sake. It prevents one number from silently changing meaning as it travels from a probability table to a dashboard or a promise. This is the central trade-off of the checkpoint: a richer model costs more explanation and measurement, but a shorter model can make a confident claim about the wrong quantity.

Repair the Broken Analysis

1. Start with the boundary

The client-visible experiment starts when the first attempt is sent and stops after an acknowledgement or the second timeout. It does not directly measure whether the user reads the message, whether the server processes a request after the client times out, or how many milliseconds the acknowledgement took.

If the decision is about user-visible delivery, this boundary may be too narrow. If the decision is about client retry load, it is appropriate. The same observed run can support different models, but each model must state its boundary.

2. List complete outcomes

Under the one-retry procedure:

• A: first attempt acknowledged.
• TA: first attempt timed out, retry acknowledged.
• TT: both attempts timed out.

The histories are mutually exclusive and exhaustive inside this boundary. AA is not a fourth outcome because the client stops after the first acknowledgement.

The event “eventual acknowledgement” is \(\{A,TA\}\), so its probability is the sum of those rows. An event is a grouping of outcomes, not a replacement for the sample space.

3. Choose variables for questions

Let \(X\) count attempts:

Let \(S\) indicate eventual acknowledgement:

The variable \(X\) answers retry-work questions. The variable \(S\) answers eventual-success questions. No single number should be forced to answer both when it discards an important distinction.

4. Name the probability model

The early toy model assigned:

It implies \(P(S=1)=0.96\), \(P(X=1)=0.80\), and \(P(X=2)=0.20\). Its expected attempt count is:

Those values are internally consistent, but they are conditional on the toy model's assumptions.

The later state model uses a healthy state with probability \(0.80\), a degraded state with probability \(0.20\), timeout rates \(0.05\) and \(0.50\), and a shared state across both attempts. It produces:

and \(E[X]=1.14\). These models do not disagree about arithmetic. They describe different assumptions about the service. A review must record which model generated the number.

5. Interpret summaries without overpromising

The expectation \(E[X]\) is a long-run average of attempt work. It does not predict that one request uses a fractional 1.2 attempts, and it does not prove that every request fits a one-attempt budget.

Variance describes spread around the mean. A threshold or reliability claim needs a probability such as \(P(S=1)\) or \(P(X\leq1)\), plus the outcome consequences that the variable may hide.

The broken note turns a workload summary into a reliability promise. That is a category error.

6. Check dependence

The toy model can be calculated as if attempts have a 20% timeout rate independently. The state model shows why that shortcut may fail. A shared degraded state makes:

The first timeout is evidence that the shared service may be degraded. Conditional probability updates the reference group; independence must be justified rather than assumed because multiplication is convenient.

7. Simulate and compare

A simulation executes the chosen state and timeout rules repeatedly. It can reveal that an eight-request batch has a 12.5% complete-failure frequency even when the model's long-run rate is 5.2%. That difference is possible sampling variation, not an automatic model failure.

For a useful check, compare:

• empirical outcome frequencies with theoretical probabilities;
• empirical mean attempts with \(E[X]\);
• clustered failures with the assumed dependence structure;
• behavior after changing one parameter, such as degraded-state frequency.

Use a fixed seed to reproduce a debugging case, then vary the seed to study ordinary variation. Simulation checks implementation and model consequences; it does not prove that the real service has the assumed states or rates.

Common Confusions

Confusion: One model must serve every decision

Why it is tempting: one dashboard number feels simpler.

Better model: keep the boundary and variable aligned with the question. Retry work, eventual acknowledgement, latency, and user harm may need separate variables.

Confusion: Different probabilities mean someone made an arithmetic mistake

Why it is tempting: the toy and state models produce different success rates.

Better model: first compare assumptions. A shared degraded state changes the distribution even when each local calculation is correct.

Confusion: A simulation frequency is the true probability

Why it is tempting: the frequency came from many generated runs.

Better model: it is an empirical result from a finite sample of the supplied model. It moves with the seed, batch size, and rules.

Confusion: Conditional probability and expectation answer the same kind of question

Why it is tempting: both compress information into one number.

Better model: \(P(A\mid B)\) updates an event probability after evidence. \(E[X]\) averages a variable across repeated runs. Neither substitutes for the other.

Check Your Understanding

Check: Which entry belongs in the model card before calculating any probability?

Think first, then reveal.

Answer: The experiment boundary and stopping rule. Without knowing what one run includes, an outcome such as TT or a success rate has no stable meaning.

Check: A team asks how much retry work to budget. Should it use \(S\), the success indicator, or \(X\), the attempt count?

Think first, then reveal.

Answer: Use \(X\) for retry work. Use \(S\) separately for eventual acknowledgement because \(X=2\) includes both successful retries and complete failures.

Check: The toy model reports \(E[X]=1.20\), while the state model reports \(E[X]=1.14\). What should you inspect first?

Think first, then reveal.

Answer: Inspect the assumptions and dependency structure. Different models can produce different valid expectations; the arithmetic is not the only source of disagreement.

Practice: Repair a Reliability Memo

A memo says:

“We observed 96 successful acknowledgements per 100 requests. Therefore, the next 100 requests will contain exactly four failures. The average of 1.2 attempts means we can provision 120 attempts and ignore bursts.”

Rewrite the memo using the model-card vocabulary. Include:

1. One explicit boundary.
2. The outcome space and the success event.
3. A distinction between expectation and a finite-batch result.
4. One dependence or burst risk.
5. One next measurement or simulation check.

Model answer

“For the client-visible boundary from first send to acknowledgement or second timeout, the complete outcomes are A, TA, and TT. Eventual acknowledgement is \(\{A,TA\}\). In the toy historical model, its probability is 0.96 and the expected attempt count is 1.20, but neither number guarantees the next batch. A shared degraded service or traffic burst can make failures dependent and can produce more than four failures in 100 requests. We should simulate the stated model across many batches, compare the batch distribution with telemetry, and measure server state or request clustering before making a capacity or reliability promise.”

The repair is not merely more cautious wording. It keeps separate the boundary, outcomes, variables, assumptions, summaries, and evidence needed for the decision.

Connections

Lessons 001–003 built the model's basic objects and summaries. Lesson 004 added conditional probability and dependence. Lesson 005 executed those assumptions through simulation. Lesson 007 now moves to a second layer: samples can vary even when the underlying process and model remain unchanged.

The checkpoint is complete when the learner can audit a probability model without silently replacing an event with a variable, an average with a guarantee, or an empirical frequency with a law.

Resources

• [COURSE] MIT OpenCourseWare: Introduction to Probability - Focus: Review sample spaces, random variables, conditional probability, and repeated trials as one connected foundation.
• [REFERENCE] MIT 18.05: Probability Terminology and Examples - Focus: Use compact tables to check marginal, joint, and conditional claims.
• [COURSE] MIT OpenCourseWare: Fundamentals of Probability - Focus: Follow the deeper path after the review checkpoint for formal probability models.

Key Takeaways

• Audit uncertainty in order: boundary, outcomes, events, variables, distribution, dependence, summaries, simulation, and limits.
• A correct calculation under one model does not validate a different model or a wider operational claim.
• Expectations summarize repeated work; conditional probabilities update evidence; empirical frequencies describe finite runs.
• Simulation can expose variation and implementation mistakes, but it cannot repair an omitted state, boundary, or dependency.
• A strong probability argument says both what the evidence supports and what it still cannot justify.