Events and uncertainty

What you will be able to do

Turn “how likely is it?” into a count of tickets. With that habit, you can read a model’s output. You can also find the chance that something goes wrong at least once in a system with several parts.

NotebookOptional: check the numbers in a notebookColab · Kaggle · GitHub

The notebook is optional: this lesson works with a calculator. It has the Tuesday table, the three checks and the lesson’s simulation in Python. Its checks say if your answer is right without showing it. It uses only Python’s standard library, so it needs no install.

Open in ColabOpen in KaggleView on GitHub

Colab and Kaggle open your own copy. They need a free Google or Kaggle account. Stuck? See the solution notebook.

Before you startWhat to know and to have readyAbout 40 minutes

What you need to know

• How to change a fraction into a decimal and a percentage: 8/100 = 0.08 = 8%, from Mathematical reading skills: Fractions, decimals and percentages.
• Module 2 is useful, but this module does not depend on it.

What you need to have ready (the notebook needs none of it)

• A calculator. A phone calculator is enough.
• Your c03-notes.md file. You made it in the “Before you start” box of Mathematical reading skills. Open it and add a heading: ## Probability. If you cannot find the file, make a new empty file with that name: this module does not use earlier answers.

The notebook was tested in Jupyter with Python 3.14.6 (standard library only).

Larkfield, again

Larkfield is an online shop for home and garden products. About 1,200 customer messages arrive each week, and each one becomes a ticket. Larkfield is building AI that suggests a team and a priority for each new ticket, and flags urgent tickets for a senior agent.

In this module, the question is chance. How often is a ticket urgent? When an alert fires, how often is it right? How many urgent tickets can arrive in one hour? Priya, the data scientist, answers each question by counting tickets first.

Where you meet this in AI

• A model’s output. The ticket model reads “My card was charged twice” and gives five numbers, one for each team. For example: payment 0.81, returns 0.09. These numbers are probabilities.
• A score for one class. An urgency model says “urgent: 0.8”. A spam filter says “spam: 0.97”. A fraud model gives each card payment a chance of fraud.
• A system with several parts. A ticket passes a language check, the team model and the priority model. Each part sometimes fails. What is the chance that at least one part fails?
• How common something is. “8% of tickets are urgent” is the starting point for every alert, every test set and every staffing plan in this module.

Count first: 100 tickets from one Tuesday

Priya takes 100 tickets from one Tuesday. For each ticket, she writes down the team that handled it and whether it was urgent.

Team	Tickets	Urgent tickets
Returns	34	1
Delivery	28	2
Payment	15	4
Warranty	13	0
Account	10	1
Total	100	8

Before you read any rule, answer one question from the table. If you pick one of these tickets at random, how likely is it to be urgent? 8 of the 100 tickets are urgent, so the chance is 8 in 100.

That is a probability: the share of cases in which something happens. You can write it as a fraction (8/100), a decimal (0.08) or a percentage (8%). A probability has no unit, and it is always between 0 (it never happens) and 1 (it always happens).

• Payment ticket, urgent: 4
• Payment ticket, not urgent: 11
• Other team, urgent: 4
• Other team, not urgent: 81

The 100 Tuesday tickets, one square each. Orange squares are payment tickets; a dot marks an urgent ticket.

Text description of the chart

A grid of 100 squares, one for each ticket. 15 squares are orange (payment team) and 85 are grey (the other four teams). A dot marks the 8 urgent tickets: 4 of them are orange squares and 4 are grey squares. So 4 tickets are urgent payment tickets, and 11 are payment tickets that are not urgent. 4 are urgent tickets from other teams, and 81 are neither.

The words for it

• An outcome is one possible result of something you observe. For “which team gets this ticket?”, one outcome is “delivery”.
• The sample space is the list of all possible outcomes. Here it is the five teams: returns, delivery, payment, warranty, account. Exactly one of them happens for each ticket.
• An event is a set of outcomes that you are interested in. “The ticket is urgent” is an event. “The ticket goes to payment or account” is also an event.

Because exactly one outcome in the sample space happens, the probabilities of all outcomes add up to 1. In the table: 0.34 + 0.28 + 0.15 + 0.13 + 0.10 = 1.00.

Complements: “not” is often easier

The complement of an event is “the event does not happen”. If 8 of 100 tickets are urgent, then 92 of 100 are not urgent.

$$P(\text{not urgent}) = 1 - P(\text{urgent}) = 1 - 0.08 = 0.92$$

Read it as: “the probability of not urgent is one minus the probability of urgent”. P( ) is short for “the probability of”. You use the complement later in this lesson, when “at least one” is hard to count but “none” is easy.

Joint events: “and” and “or”

A joint event combines two events. Count it from the grid or the table:

Event	Count it	Probability
Payment ticket	15 of 100	0.15
Urgent	8 of 100	0.08
Payment ticket and urgent	the orange squares with a dot: 4	0.04
Payment ticket or urgent (or both)	15 + 8 − 4 = 19	0.19

For “or”, the 4 urgent payment tickets are in both groups. If you add 15 and 8, you count them twice, so you subtract them once. As a rule:

$$P(A \text{ or } B) = P(A) + P(B) - P(A \text{ and } B)$$

Independence: does one event change the other?

Two events are independent when knowing one tells you nothing about the other. If “payment ticket” and “urgent” were independent, payment tickets would be urgent as often as all tickets: 8 in 100.

Test it with counts. 15 tickets are payment tickets. If 8% of them were urgent, you would expect 15 × 0.08 = 1.2 urgent payment tickets. Priya counts 4. Payment tickets are urgent much more often, which makes sense: “charged twice” cannot wait. So these two events are not independent.

Only for independent events, you can multiply the probabilities to get the joint probability:

$$P(A \text{ and } B) = P(A) \times P(B) \quad \text{(only if A and B are independent)}$$

Here, 0.15 × 0.08 = 0.012, but the real share is 0.04. The rule gives the wrong answer because its condition is not true.

A model’s output is a probability over a sample space

Now the same ideas in a model. The ticket model reads T-2207, “My card was charged twice for one order”, and gives one number for each team.

The team model's output for ticket T-2207. The five numbers cover the whole sample space, so they add up to 1.

Text description of the chart

A column chart with five columns, one for each team. Payment 0.81 (orange, the highlighted team), returns 0.09, account 0.06, delivery 0.03, warranty 0.01. Together they add up to 1.00.

Read the output with the words from this lesson:

• The sample space is the five teams. The five numbers add up to 0.81 + 0.09 + 0.06 + 0.03 + 0.01 = 1.00.
• The complement: the chance that T-2207 is not a payment ticket is 1 − 0.81 = 0.19.
• “Account or returns” is 0.06 + 0.09 = 0.15. These two events cannot both happen (a ticket goes to one team), so nothing is counted twice.

An urgency model gives one number, for example “urgent: 0.8”. The complement, “not urgent”, is 0.2. What does 0.8 mean for one ticket? The ticket is urgent or it is not. The number makes sense as a count over many tickets: of many tickets that get 0.8, about 80 in 100 should be urgent. If that is true, the model is calibrated. Many models are not, and Module 6 shows how to check it.

At least one of three checks fails

Each new ticket passes three automatic checks: a language check, the team model and the priority model. Each check fails (it times out or gives no answer) for about 2 in 100 tickets. Grace, the support lead, asks: “How many tickets have at least one failure?”

“At least one fails” has many cases: only the first, only the second, the first and the third, and so on. The complement has only one case: none fails. So Priya counts the complement first.

If the three checks fail independently, multiply the chances that each one works:

Step	Calculation	Result
One check works	1 − 0.02	0.98
All three work	0.98 × 0.98 × 0.98	0.941
At least one fails	1 − 0.941	0.059, about 5.9%
In one week of 1,200 tickets	1,200 × 0.0588	about 71 tickets

Three small chances of 2% give almost 6%. The more parts a system has, the more often something goes wrong somewhere.

• Each check fails 2%
• Each check fails 5%

The chance that at least one check fails grows with the number of checks. Both lines assume that the checks fail independently.

Text description of the chart

Two lines for 1 to 10 checks. With a 2% failure chance per check: 2% for 1 check, 5.9% for 3, 9.6% for 5 and 18.3% for 10. With a 5% failure chance per check: 5% for 1 check, 14.3% for 3, 22.6% for 5 and 40.1% for 10. Both lines rise steadily, and the 5% line rises faster.

When independence breaks

Mei, the data engineer, reads the calculation and adds a fact. All three checks read from the same ticket database. When the database is slow, all three checks fail together.

Now the failures are not independent. They share one cause. Compare the two pictures for “all three fail on the same ticket”:

• Independent: 0.02 × 0.02 × 0.02 = 0.000008, or 8 tickets in a million.
• One shared cause: when the database is slow, all three fail at once. If that happens for 2 in 100 tickets, then “all three fail” is about 2 in 100, which is 2,500 times more often.

Tickets can be dependent too. During a payment outage, 40 customers write “charged twice” within one hour. If one of those tickets is urgent, the next one probably is too. A plan that treats each ticket as a separate coin flip expects urgent tickets to arrive evenly. They arrive in a burst instead.

Independence is an assumption, not a fact. Before you multiply chances, ask: do these events share a cause?

Worked example: Priya reads the outage report

Last month, the ticket database was slow for 5 hours. Omar, the product manager, asks Priya if the 3-check design is safe.

1. What the independent calculation says. At least one check fails for 5.9% of tickets. All three fail for 8 tickets in a million, so almost never.
2. What the logs say. In the 5 slow hours, 310 tickets arrived. All three checks failed on 296 of them.
3. Why the numbers differ. The checks share the database, so their failures are not independent. The multiplication was correct arithmetic, but it answered the wrong question.
4. What Priya recommends. If all three checks fail, send the ticket to the normal queue and show it to a person. Do not drop it. Then test the system with the database switched off, because that is the case the multiplication hid.

Guided practice: count events in the Tuesday table

Use the table of 100 Tuesday tickets.

1. In c03-notes.md, add a heading: ### Guided practice: events and uncertainty.
2. Write the probability that a ticket is a delivery ticket. Expected: 28/100 = 0.28.
3. Write the probability that a ticket is not a delivery ticket, with the complement. Expected: 1 − 0.28 = 0.72.
4. Write the probability that a ticket is a delivery ticket and urgent. Expected: 2/100 = 0.02.
5. Calculate how many urgent delivery tickets you expect if “delivery” and “urgent” are independent: 28 × 0.08. Expected: 2.24.
6. Compare 2.24 with the real count, 2. Write one sentence: are the two events close to independent?

Show an example answer

Question	Answer
P(delivery)	28/100 = 0.28
P(not delivery)	1 − 0.28 = 0.72
P(delivery and urgent)	2/100 = 0.02
Expected if independent	28 × 0.08 = 2.24
Real count	2

2 is very close to 2.24, so “delivery” and “urgent” look independent in this sample. A delivery ticket is urgent about as often as any ticket. Compare the payment team: 1.2 expected, 4 real. With only 100 tickets, small differences can come from chance. Module 5 shows how to judge that.

Check: your complement and your probability add up to exactly 1.

Independent variation: less reliable checks

Change one condition. A new version of the priority model is slower, and Tomás, the AI engineer, measures that each check now fails for 5 in 100 tickets. The checks still fail independently.

Calculate the chance that at least one of the three checks fails, and the number of tickets with a failure in a week of 1,200. Then read the chart above: how many checks can the system have before the chance of at least one failure is above 25%?

Show an example answer

• One check works: 1 − 0.05 = 0.95.
• All three work: 0.95 × 0.95 × 0.95 = 0.857.
• At least one fails: 1 − 0.857 = 0.143, about 14.3%.
• In a week: 1,200 × 0.1426 = about 171 tickets.
• From the orange line: 5 checks give 22.6%, and 6 checks give 26.5%. So at 6 checks, the chance is above 25%.

A change from 2% to 5% per check looks small. For the whole system, it is the difference between about 71 and about 171 tickets a week.

Run Python in your browser

Optional: simulate 100,000 tickets

This box is optional. It checks the 5.9% result with a simulation. The code gives each of 100,000 tickets three random checks, and counts the tickets with at least one failure. Run it, then change FAIL to 0.05 and compare with your answer above. The simulation result changes a little with the seed, but it stays close to the formula.

Python code (you can change it)import random random.seed(1) FAIL = 0.02 # each check fails for 2 in 100 tickets TICKETS = 100_000 with_failure = 0 for ticket in range(TICKETS): fails = [random.random() < FAIL for check in range(3)] if any(fails): with_failure += 1 print("Share with at least one failure:", with_failure / TICKETS) print("Formula 1 - 0.98 ** 3:", round(1 - 0.98 ** 3, 4))

Common mistake

Multiplying chances that share a cause

Symptom: a design document says “all three checks fail together for only 8 tickets in a million, so we do not need a fallback”. Then the database is slow for one afternoon, and almost 300 tickets get no team and no priority.

Cause: the calculation multiplied the three failure chances. Multiplication is correct only for independent events. The checks share a database, so one slow database makes all of them fail together.

Fix: for each pair of events, ask if they share a cause: the same database, the same outage, the same customer, the same day. If they do, do not multiply. Use the logs to count how often they happen together, and plan for the shared failure.

Check your understanding

The team model gives ticket T-2310 these outputs: returns 0.62, delivery 0.30, the other three teams 0.08 together. What is the chance that the ticket is not a returns ticket? Why can you be sure the five outputs add up to 1?

Show the answer

The chance of “not returns” is 1 − 0.62 = 0.38 (or 0.30 + 0.08 = 0.38). The outputs add up to 1 because the five teams are the whole sample space: each ticket goes to exactly one team. A team model with outputs that do not add up to 1 is not giving probabilities over the five teams.

Check your understanding

Predict: the three checks all use the same database. Is the real chance that all three fail on the same ticket higher or lower than 0.02 × 0.02 × 0.02? Explain in one or two sentences.

Show the answer

Higher, much higher. 0.02 × 0.02 × 0.02 assumes that the checks fail independently. With a shared database, one slow moment makes all three fail together. So “all three fail” happens about as often as the database is slow, not 8 times in a million.

Check your understanding

In 200 tickets, 60 are delivery tickets and 20 are urgent. 6 tickets are urgent delivery tickets. Do 'delivery' and 'urgent' look independent? Show the count that you compared.

Show the answer

Yes. If they are independent, delivery tickets are urgent as often as all tickets: 20/200 = 0.10. So you expect 60 × 0.10 = 6 urgent delivery tickets. The real count is 6, so the data agrees with independence.

Recap

• A probability is a share of cases: count the tickets where the event happens, and divide by all tickets.
• The sample space lists every possible outcome. A model’s outputs over a sample space add up to 1.
• The complement is 1 minus the probability. Use it for “at least one”: 1 − P(none).
• For “or”, do not count the overlap twice. For “and”, multiply only when the events are independent.
• Independence is an assumption. Events that share a cause, such as one database or one outage, are not independent.

Next, you look at probability inside a group: how often a flagged ticket is really a payment problem.

Next: Conditional probability