Uncertainty Belongs in the Model

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

• Represent an uncertain input with a range or set of scenarios instead of a fake exact value.

• Separate confidence in the evidence from certainty about the outcome.

• Identify when a decision changes across plausible cases and write an update trigger.

Idea in one sentence: Uncertainty is information about the limits of a model, so hiding it as one precise number makes the model look stronger while making decisions more fragile.

Core Insight

Imagine the support team from the previous lesson. Its current backlog is 44 tickets. The manager asks a simple question:

How many days until the backlog is below 25?

An analyst opens a spreadsheet and answers, “Four days.” The calculation uses 12 incoming tickets and 17 resolved tickets per day.

The number is neat. The evidence is not.

On a quiet day, 9 tickets may arrive. During a product incident, 16 may arrive. The new engineer may resolve 10 tickets while learning the service or 14 after training. The automation fix may reduce arrivals next week, or it may reveal a second problem instead.

The model has uncertainty at its inputs, relationships, and timing. The answer “four days” compresses all of that into one point estimate.

That compression can be useful for a quick conversation. It becomes dangerous if the team treats it as a guarantee, schedules an irreversible decision around it, or hides the conditions that would make it wrong.

This is the pressure behind the lesson:

A model should show not only what it predicts, but how much support and stability that prediction has.

What Uncertainty Means Here

Uncertainty does not mean that nothing can be known. It means that several outcomes remain compatible with the information we have, or that the model's relationships are not well established.

There are at least three useful sources to separate.

Variable conditions

Some quantities vary even when the model is correct. Ticket arrivals change with user behavior, incidents, time of day, and releases. We may know the pattern but not the exact value tomorrow.

Missing knowledge

Some relationships are uncertain because we have not measured them well. We do not yet know how much training the new engineer needs or how many tickets the automation fix will prevent.

Model limits

The model may omit a factor that changes the result. A new dependency, policy change, or customer migration can make yesterday's range too narrow.

Plain meaning:

Uncertainty is the space of outcomes or explanations that the current model cannot distinguish confidently.

In this scenario:

The team can estimate a range for arrivals and resolution, but it cannot know which exact pair will occur on each day.

Technical terms:

Variability is change in the situation. Uncertainty is limited confidence about what value, relationship, or outcome will apply. Ignorance is a gap where we may not even know which factor to ask about yet.

The words overlap in ordinary speech. The practical distinction is enough for this lesson: name what varies, what is unknown, and what the model may be missing.

The Naive Model: One Number Hides Many Conditions

The manager's point forecast assumes:

arrivals per day = 12
resolved per day = 17
net change = -5 tickets per day

At 44 tickets, the model predicts:

44 -> 39 -> 34 -> 29 -> 24

So the answer is four days.

The arithmetic is fine. The problem is that the inputs are presented as if they were stable facts rather than estimates with conditions.

If arrivals are 16 and resolution is 10, the net change is positive six. The same starting backlog becomes larger. If arrivals are 9 and resolution is 14, the backlog falls by five each day and the team reaches the target sooner.

The model's output is sensitive to the inputs. That sensitivity belongs in the model, not in a private worry that disappears from the dashboard.

Worked Path: Replace a Point Forecast with Scenarios

Let us build a small range model for the next five days.

Starting state

current backlog: 44 tickets
planning horizon: 5 days

The team reviews recent evidence and chooses plausible working ranges:

new tickets per day: 9 to 15
resolved tickets per day: 10 to 14

These are not promises. They are a statement about the cases the team currently considers plausible.

Step 1: Calculate the net change range

The most favorable daily change is:

9 arrivals - 14 resolved = -5 tickets

The least favorable daily change is:

15 arrivals - 10 resolved = +5 tickets

So the backlog can change by roughly -5 to +5 per day under this simple range model.

Step 2: Propagate the range

After five days:

best case: 44 - (5 * 5) = 19 tickets
worst case: 44 + (5 * 5) = 69 tickets

The model does not claim that 19 and 69 are equally likely. It says the current information does not justify pretending that one exact result is known.

Step 3: Add a middle scenario without calling it certain

The team chooses a planning scenario of 11 arrivals and 12 resolved per day:

44 + (5 * 11) - (5 * 12) = 39 tickets

The middle scenario says the backlog probably improves slowly under current conditions. The range says that a bad week could leave the queue much larger.

Step 4: Ask whether the decision changes

The manager has two candidate actions:

• keep staffing unchanged and review in five days;
• move another engineer today, accepting a cost to planned work.

If the service can tolerate a backlog below 70, the range may support waiting. If the service becomes unsafe or contractually unacceptable above 50, the worst-case branch changes the decision. Uncertainty matters when plausible outcomes cross an action boundary.

Step 5: Write an update trigger

The model should say what would change confidence:

• arrivals exceed 15 for two consecutive days;
• resolution stays below 10 after training;
• the automation fix changes arrivals by less than 2 tickets per day;
• a new incident creates a different class of tickets.

The trigger turns uncertainty into a monitoring plan. The team does not need to solve the future before acting. It needs to know what evidence will make the next update more informed.

So far, the path is:

uncertain inputs
-> range or scenarios
-> propagated outcomes
-> action threshold
-> update trigger

Confidence Is Not a Promise

People often say, “I am 80% confident.” That sentence can mean several things:

• the evidence is usually reliable;
• the person has a strong feeling;
• four out of five similar forecasts were correct;
• the outcome has an estimated probability of 0.8.

Those meanings are not interchangeable.

For a beginner model, write the basis of confidence next to the claim:

The confidence label does not make the claim true. It records how strongly the current evidence supports using the claim in this model.

When a claim matters, add a calibration habit: compare old confidence statements with later outcomes. If “high confidence” repeatedly fails, the model's confidence language needs repair.

Ranges Are Not Automatically Better

A range can be too narrow, too wide, or disconnected from evidence.

• A too-narrow range creates fake precision. It says “10 to 11” because a wider answer feels embarrassing, not because observations support it.
• A too-wide range avoids commitment. “Between zero and one hundred” may be true but useless for a staffing decision.
• An unstructured range hides different conditions. If 9 arrivals happen only on quiet days and 15 only during incidents, combine the range with scenarios rather than treating all days as one population.

The useful question is:

What evidence justifies this range, and what decision can it support?

The goal is not to sound cautious. The goal is to make the model honest enough to guide action.

Decision Sensitivity

Not every uncertainty deserves the same attention. Focus on uncertainty that could change the decision.

Suppose the manager is deciding whether to schedule a second engineer. If both the best and worst cases stay below the service limit, extra precision may not matter. If the best case is safe and the worst case violates the limit, the decision is sensitive.

A simple sensitivity table helps:

This table prevents a common mistake: spending hours estimating a low-impact variable while ignoring the unknown that decides whether users will be harmed.

Trade-offs and Limits

The central trade-off is that uncertainty slows commitment and complicates communication, but representing it prevents fake precision and reveals sensitive decisions.

Ranges cost attention. They require more explanation than one number, and different readers may use the same range to justify opposite actions. Monitoring triggers also cost time and can create alert fatigue.

Uncertainty does not protect us from unknown unknowns. A range built from normal weeks may not include a new dependency failure. Nor does uncertainty automatically choose the right value or action. Values, risk tolerance, and reversibility still matter.

You can see the boundary when the range stops covering observed outcomes, when confidence labels are not compared with later results, or when the model keeps the same action despite scenarios crossing different risk thresholds.

Common Confusions

Confusion: A range means every value is equally likely

Why it is tempting:

The model shows endpoints and people read the interval as a probability statement.

Better model:

A range says which values are currently considered plausible. It does not assign equal likelihood unless the model explicitly says so.

Confusion: Confidence is the same as certainty

Why it is tempting:

“High confidence” sounds like a guarantee.

Better model:

Confidence describes support from current evidence. A high-confidence model can still fail when conditions change or an important factor was omitted.

Confusion: Uncertainty means we should wait before acting

Why it is tempting:

Action feels irresponsible while the model is incomplete.

Better model:

Uncertainty can change the action, the size of the action, its reversibility, or the monitoring plan. Waiting is only one possible response.

Confusion: More decimals reduce uncertainty

Why it is tempting:

39.2 days looks more scientific than “about five weeks.”

Better model:

Precision in arithmetic is not precision in the world. If arrivals and resolution are uncertain, extra decimals only decorate the uncertainty.

Check Your Understanding

Check: A team forecasts that an incident will be resolved in exactly four hours, but its historical resolution time ranges from two to twelve hours. What is the first repair?

Think first, then reveal.

Answer: Represent the outcome as a range or scenarios, explain what evidence supports each case, and state which threshold would change the mitigation plan. The exact four-hour value may remain as a planning case, not as a promise.

Check: A forecast range is 20–80 visitors for an event. Both values are plausible, but staffing one person is safe at 20 and unsafe above 50. What does the model need next?

Think first, then reveal.

Answer: It needs a decision threshold and better information or a robust plan for the high case. The range matters because it crosses the point at which the action changes.

Practice: Add Uncertainty to a Model Card

Return to one of the model cards from the earlier lessons: a commute, a library queue, a software incident, or a household plan.

Add:

1. two inputs that are uncertain;
2. a plausible range or two named scenarios for each;
3. one outcome range produced by those inputs;
4. a confidence statement with its evidence;
5. the threshold where the decision changes;
6. one update trigger and the time when you will check it.

A good answer should not hide behind a very wide interval. It should explain why the range is plausible, what it leaves out, and which uncertainty actually matters to the decision.

Connection to the Next Lesson

One uncertain model may fail because its assumptions are wrong. Another model may explain the same situation better. The next lesson asks how to compare several models without collecting frameworks as decoration:

Which model reveals the useful pattern for this question, and which blind spot does each alternative carry?

Resources

• [BOOK] The Model Thinker — Focus: Compare models and avoid treating one elegant forecast as the whole situation.
• [BOOK] Thinking in Systems — Focus: Delays, uncertainty, and the limits of prediction in dynamic systems.
• [ARTICLE] Mental Models I Find Repeatedly Useful — Focus: Use ranges, assumptions, and update habits instead of false precision.

Key Takeaways

• Uncertainty can come from variable conditions, missing knowledge, or limits in the model.
• Ranges and scenarios show what the evidence supports without pretending one exact outcome is known.
• Confidence describes support, not certainty; it should be tied to evidence and checked against later outcomes.
• Pay special attention to uncertainty that crosses an action or risk threshold.
• An update trigger turns uncertainty into a practical plan for learning and revision.