Expectation Is a Summary, Not a Promise

LESSON

Probability, Random Processes, and Statistical Thinking

003 25 min beginner

Expectation Is a Summary, Not a Promise

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

  • Compute the expectation and variance of a small discrete random variable.

  • Explain why an expected value is a long-run average, not a prediction of the next run.

  • Decide when an average is enough and when the distribution or its tail also matters.

Idea in one sentence: Expectation compresses a distribution into a probability-weighted average, while variance reminds us how far individual runs can move away from that average.

Core Insight

Lesson 002 turned the notification client's outcome histories into a random variable. Let (X) be the number of client attempts used by one request:

Outcome Meaning (X)
A acknowledged on the first attempt 1
TA first attempt timed out, retry acknowledged 2
TT both attempts timed out 2

After grouping the outcomes, the distribution is:

\[ P(X=1)=0.80,\qquad P(X=2)=0.20 \]

The operations team now asks a different question:

If we receive many requests, how much client-attempt work should we budget for?

Reading only the most likely value is not enough. Most requests use one attempt, but some use two. We need a summary that gives more weight to values that occur more often. That summary is the expectation (also called the expected value or mean).

For a discrete variable, the rule is:

\[ E[X]=\sum_x xP(X=x) \]

For this request:

\[ E[X]=1(0.80)+2(0.20)=0.80+0.40=1.20 \]

The answer is 1.2 attempts per request on average.

There is no request that uses 1.2 attempts. That is not a problem. The expectation is a summary across repeated runs, not a description that every single run must match.

See the Pattern Before the Formula

Imagine 10 requests whose outcomes follow the same proportions: eight A requests and two requests that need a retry (TA or TT).

\[ \text{total attempts}=8(1)+2(2)=12 \]

The average is:

\[ \frac{12\text{ attempts}}{10\text{ requests}}=1.2\text{ attempts per request} \]

With 1,000 requests, the same planning calculation gives approximately 1,200 attempts. The value becomes useful for capacity, budget, and work estimates precisely because it describes accumulation over many runs.

This is the central interpretation:

An expectation tells us the average amount that accumulates when the process is repeated under the same model.

It does not tell us what the next request will do. The next request still uses either one or two attempts in this model.

A Worked Calculation: Expectation Step by Step

Use this checklist whenever you calculate a discrete expectation:

  1. List every value the variable can take.
  2. Attach the probability of each value.
  3. Multiply each value by its probability.
  4. Add the products.
  5. Translate the result back into the units of the variable.

For (X):

(x) (P(X=x)) contribution (xP(X=x))
1 0.80 0.80
2 0.20 0.40
Total 1.00 1.20

The multiplication is not a claim that a fractional request exists. It is a way to let common values contribute more than rare values to one long-run summary.

Expectation is also linear. If a request has an attempt count (X) and each attempt consumes one unit of a resource, then the expected resource use is (E[X]) units. For 1,000 independent or merely similarly distributed requests, the expected total attempt count is:

\[ E[X_1+\cdots+X_{1000}]=E[X_1]+\cdots+E[X_{1000}]=1200 \]

The linearity rule does not require the requests to be independent. Independence matters for other calculations, but adding expected amounts is safe when the individual expectations exist.

Most Likely Is Not the Same as Expected

In this example, the most likely value is (1), because (P(X=1)=0.80). The expected value is (1.2). Both statements are correct because they answer different questions:

The difference matters in operations. If a runbook must choose the number of attempts for one request, it cannot allocate “1.2 attempts.” It must handle the possible values and the retry rule. If a capacity plan estimates total work for a large population, 1.2 attempts per request is a useful first estimate.

An expected value is not necessarily a value the variable can take, and it is not necessarily the mode or the median. Do not substitute one summary for another without checking the question.

Variance Shows the Spread Hidden by the Average

Two systems can have the same expectation but very different operational risk. To describe how widely values vary around the mean, use variance.

For a discrete variable:

\[ \operatorname{Var}(X)=E[(X-E[X])^2] \]

The procedure is:

  1. Find the distance from each value to the mean.
  2. Square the distance so positive and negative deviations do not cancel.
  3. Weight each squared distance by its probability.
  4. Add the weighted values.

For (E[X]=1.2):

\[ \begin{aligned} \operatorname{Var}(X) &=0.80(1-1.2)^2+0.20(2-1.2)^2\\ &=0.80(0.04)+0.20(0.64)\\ &=0.032+0.128=0.16 \end{aligned} \]

The variance is (0.16) attempts squared. Squared units are mathematically convenient but not very intuitive to read. The standard deviation is the square root:

\[ \operatorname{sd}(X)=\sqrt{0.16}=0.4\text{ attempts} \]

You do not need to treat (0.4) as a guarantee that every request is within 0.4 attempts of the mean. It is a scale for the typical spread under this model. The full distribution remains the safest way to answer exact probability questions.

When the Average Is Not Enough

Suppose the team uses the expected 1.2 attempts to reserve capacity. That can be reasonable for estimating total work, but it cannot answer all operational questions.

Consider these decisions:

The outcome TT is only 4% of requests, but it carries a different user consequence from TA: both use two attempts, yet only TA eventually succeeds. The attempt-count variable intentionally hides that distinction. If the decision is about reliability, pair (X) with a success variable (S), or return to the original outcome space.

This is the trade-off:

A compact summary is easy to communicate and calculate, but compression can hide rare events, asymmetry, or a distinction that the decision needs.

An average is therefore a starting point for reasoning, not permission to stop inspecting the distribution.

A Transfer Example: Batch-Job Cost

Move to the batch-job outcomes from lesson 001:

Define a simple cost variable (C):

The empirical probabilities are (0.75), (0.15), and (0.10). Therefore:

\[ E[C]=1(0.75)+2(0.15)+5(0.10)=0.75+0.30+0.50=1.55\text{ units} \]

The planning interpretation is 1.55 attention units per job on average. It is not a forecast that the next job will cost 1.55 units. The next job has one of the modeled outcomes.

The number also hides an important fact: the 10% failed jobs contribute 0.50 units to the mean, nearly one third of the total expected cost. A team deciding whether to reduce failures should inspect the outcome probabilities and costs, not only repeat the mean in a dashboard.

Edge Cases and Common Confusions

Confusion: “Expected” means guaranteed

Why it is tempting: everyday language uses “expected” for a likely event.

Better model: in probability, expectation is a weighted average. A rare, expensive outcome can raise it even when most runs are cheap.

Confusion: The expected value is the most typical next value

Why it is tempting: the mean feels like the center of the data.

Better model: ask whether the decision needs a mode, a median, a threshold probability, or a long-run average. They are different summaries.

Confusion: Equal means imply equal risk

Why it is tempting: two systems with the same average appear equivalent in a summary table.

Better model: compare variance, tail probabilities, and the consequences of rare outcomes. A mean cannot reveal the shape of a distribution by itself.

Confusion: Variance is a probability

Why it is tempting: both are numbers between or near 0 and 1 in small examples.

Better model: variance measures squared spread. It does not say that an event happens with that probability.

Check Your Understanding

Check: For (P(X=1)=0.80) and (P(X=2)=0.20), what is (E[X])?

Think first, then reveal.

Answer: (1(0.80)+2(0.20)=1.20) attempts. The value describes the average across many comparable requests.

Check: Is 1.2 the most likely number of attempts for one request?

Think first, then reveal.

Answer: No. One request uses either 1 or 2 attempts here, and 1 is the most likely value. The expectation is not a literal next-run outcome.

Check: What does the variance calculation add to the expectation?

Think first, then reveal.

Answer: It describes the amount of spread around the mean. It warns us that the same average can arise from concentrated values or from a distribution with more extreme outcomes.

Check: A dashboard shows an average of 1.2 attempts. What should you inspect before promising that every request fits a one-attempt budget?

Think first, then reveal.

Answer: Inspect the distribution or threshold probability, especially (P(X=1)), retry behavior, and the separate failure probability (P(TT)). The mean alone cannot make that promise.

Practice: Budget a Repeated Batch

Use the batch-job cost variable (C) from the transfer example. Assume the same probabilities continue for 1,000 jobs.

  1. Estimate the total attention units using the expectation.
  2. Estimate how many failed jobs the average model implies.
  3. Explain why those two estimates are not a guarantee about the actual batch.
  4. Name one additional quantity you would report to an incident manager.

Model answer

The expected total is:

\[ 1000E[C]=1000(1.55)=1550\text{ attention units} \]

The expected number of failed jobs is (1000(0.10)=100). These are long-run planning values. An actual batch can contain more or fewer failures and can therefore require more or less attention. The incident manager should also receive the failure probability, an interval or simulated range for the total, and the operational consequence of a failure. The right extra measure depends on whether the priority is capacity, deadline reliability, or user harm.

Connections

Lesson 002 defined random variables and distributions. This lesson compresses one distribution into expectation and variance while keeping the original probabilities available for decisions that need more detail. Lesson 004 will show why dependence changes how evidence accumulates: even a good average can mislead when observations are not behaving like separate, comparable runs.

Later lessons will add simulation, sampling variation, intervals, mixtures, and heavy tails. Each extension asks the same question: what information did the summary keep, and what risk might it have hidden?

Resources

Key Takeaways

PREVIOUS Random Variables Turn Outcomes into Distributions NEXT Dependence Changes the Meaning of Evidence