Rare events and tails

Most of the time, systems operate near ordinary conditions.

Most journeys are uneventful.

Most transactions are legitimate.

Most machines do not fail.

Most weather is not extreme.

Most AI predictions are not catastrophic.

But many of the outcomes we care about most live in the tails of probability distributions.

These are outcomes that are:

unusual,
extreme,
low probability,
potentially high consequence.

Rare events matter because low probability does not mean low importance.

In many real systems, the tails determine:

safety,
resilience,
insurance cost,
reserve requirements,
system design.

What is a tail?

Recall that a probability distribution describes how probability is spread across possible outcomes.

The central region contains the more common outcomes.

The tails contain the more extreme ones.

Suppose electricity demand is usually around:

40 GW

Most days may fall between:

35 and 45 GW.

But occasionally demand reaches:

50 GW

or:

55 GW.

Those extreme values lie in the upper tail.

Rare does not mean impossible

Suppose an event has probability:

0.1%.

That means:

1 in 1,000

on average under comparable conditions.

It is rare.

But if the system operates:

one million times,

we may expect many such events.

Scale changes how rare events should be interpreted.

Small probability × large exposure

Suppose an AI system has a serious error probability of:

0.01% per prediction.

That sounds tiny.

At:

1,000 predictions

we might expect roughly:

0.1 serious errors.

At:

1 billion predictions

the same rate corresponds to roughly:

100,000 serious errors.

This is why tiny error probabilities can still matter in systems operating at enormous scale.

Per-event risk is not lifetime risk

Suppose a device has:

1% probability of failure per year.

One year may seem relatively safe.

But over many years, cumulative exposure changes the picture.

Likewise, if a user interacts with an AI system:

thousands of times,

the probability of encountering at least one failure can become much larger than the per-interaction error rate.

Whenever you see a probability, ask:

Per what?

Tail events can dominate consequences

Suppose an electricity system usually operates perfectly.

But once every few years, a rare combination occurs:

high demand,
low wind,
generator failure,
network constraint.

That one event may create more harm than thousands of ordinary periods combined.

So average performance can look excellent while tail performance remains poor.

Expected value can hide tails

Suppose two investments have the same expected return.

Investment A

Returns are tightly concentrated around the mean.

Investment B

Usually performs well but occasionally loses nearly everything.

Their expected values may be identical.

The tail risk is not.

This is another reason expected value should not be used alone.

Variance may not capture tails well either

Variance measures overall spread.

But two distributions with similar variance can have very different extreme-event probabilities.

A distribution may have:

ordinary values most of the time,
very occasional enormous deviations.

These heavy tails can be particularly dangerous.

Heavy-tailed distributions

A heavy-tailed distribution assigns more probability to extreme outcomes than a normal bell-shaped distribution would.

This means very large deviations occur more frequently than we might expect from a simple normal model.

Examples can appear in:

financial losses,
wealth,
insurance claims,
internet traffic,
natural disasters,
system failures.

If we assume thin tails when reality is heavy-tailed, we may dramatically underestimate extreme risk.

The normal distribution can create false comfort

The normal distribution is extremely useful.

But it places very little probability far from the mean.

If a real process produces extremes more often than the normal model predicts, a supposed:

one-in-a-million event

may occur far more frequently.

This is why the choice of distribution matters.

Six standard deviations does not always mean impossible

In a perfectly normal distribution, an observation many standard deviations from the mean is extraordinarily rare.

But real systems may not be normal.

If:

correlations change,
processes have heavy tails,
the system shifts regimes,

extreme events can occur much more often.

Statistical language should not override evidence about the actual system.

Rare events are hard to learn from data

Suppose catastrophic machine failure occurs:

once every 100,000 operating hours.

A dataset containing:

10,000 hours

may contain:

zero failures.

What can we learn about failure probability?

Not much.

The event that matters most may be almost absent from the training data.

This creates a fundamental problem.

The data is richest where events are common

Machine learning tends to learn best where it has many examples.

But safety often depends on:

the unusual cases.

For example, an autonomous vehicle may see millions of examples of:

ordinary lane following,
normal traffic.

But far fewer examples of:

unusual pedestrian behaviour,
debris falling onto the road,
extreme weather,
rare vehicle types.

The tail is precisely where data is sparse.

Rare classes create class imbalance

Suppose fraud occurs in:

0.1% of transactions.

Then a dataset of:

1 million transactions

contains roughly:

1,000 fraudulent

and:

999,000 legitimate.

A naive model could predict:

not fraud

for every transaction and achieve:

99.9% accuracy.

That sounds excellent.

It is also useless for detecting fraud.

Rare events expose the limitations of simple accuracy metrics.

Accuracy can hide complete failure

Suppose a medical condition affects:

1 in 10,000 people.

A model that always predicts:

No disease

achieves:

99.99% accuracy.

Yet it detects:

zero cases.

This is why later we will study:

precision,
recall,
false positives,
false negatives.

Tail events require different evaluation.

Rare-event detection creates false positives

Suppose a security system is searching for an event that occurs:

1 in 1 million cases.

Even a very low false-positive rate may generate more false alarms than true detections.

This is the base-rate problem again.

Rare-event systems must be extremely careful about:

specificity,
calibration,
operational consequences.

A detector can be "99% accurate" and still fail badly

Suppose:

1 in 10,000 people

has a condition.

A test correctly detects:

99% of true cases.

But it falsely flags:

1% of healthy people.

Testing one million people produces roughly:

100 true cases,
about 99 true positives,
around 9,999 false positives.

The rare base rate dominates.

A positive result still requires careful interpretation.

Tails matter differently depending on consequence

Suppose an AI recommendation system occasionally suggests a bad film.

Low consequence.

Now suppose an autonomous vehicle occasionally fails to detect a pedestrian.

Much higher consequence.

The same numerical error probability can have radically different importance.

So:

TAIL PROBABILITY

must be considered together with:

TAIL CONSEQUENCE.

Extreme outcomes can dominate risk

Suppose:

99.99% chance of €0 loss,
0.01% chance of €1 billion loss.

The expected loss is substantial.

Even though the bad event is rare, its magnitude dominates the risk calculation.

This is why catastrophic events can drive system design.

Tail risk in infrastructure

Consider an electricity system.

It might be designed around:

average demand.

But reliability depends on:

high-demand tail.

At the same time, renewable availability has its own:

low-output tail.

The dangerous system state may occur when:

high demand

and:

low supply

happen together.

Tail risk often comes from combinations.

Joint tails

Suppose:

D = demand

and:

W = wind generation.

The critical event might be:

D very high AND W very low.

Even if each event is individually unusual, their joint probability matters.

If the variables are correlated, calculating that probability becomes more complicated.

Correlation can increase tail risk

Suppose generators are geographically dispersed.

If their failures are independent, simultaneous failure is unlikely.

But suppose all rely on the same:

fuel supply,
software system,
weather condition.

Failures can become correlated.

The tail of total available capacity becomes much worse.

Shared dependencies create systemic risk.

Diversification can fail in the tail

Two assets may appear weakly correlated during normal conditions.

Then a crisis occurs.

Everyone sells.

Correlation rises sharply.

What appeared diversified becomes concentrated.

This is sometimes described as:

correlations go to one in a crisis

The exact statement is not universally true, but the intuition matters:

relationships can change precisely during extreme events.

Systemic tail risk

A system may appear safe when components are considered separately.

But connections between them can create cascades.

For example:

Component A fails

↓

load shifts to B

↓

B overloads

↓

C becomes overloaded

↓

system-wide failure

The tail event emerges from network interactions.

This is systemic risk.

Cascading failures

Cascades occur when one failure changes the conditions faced by other components.

Examples include:

electricity blackouts,
financial contagion,
supply-chain collapse,
communication-network failures.

The event is not simply:

many independent failures happen together.

The first failures cause later ones to become more likely.

Rare events can emerge from ordinary components

Suppose every component is:

99.9% reliable.

That sounds excellent.

But a complex system may contain:

millions of components.

Interactions among them may create failure modes that are difficult to infer from component reliability alone.

System reliability is not simply:

component reliability × number of components.

Architecture matters.

Black swans

The term black swan is often used for events that are:

extremely surprising,
high impact,
difficult to predict using previous experience.

The idea is useful, but should not become an excuse.

Sometimes events called "black swans" were actually:

known possibilities,
poorly prepared for,
assigned inconveniently low probability.

We should distinguish:

genuinely unforeseen events

from:

known tail risks that were ignored.

Grey rhinos

A related idea is the grey rhino:

a large, obvious risk that is visible but neglected.

For example:

ageing infrastructure,
known flood exposure,
predictable capacity shortages.

The event may not be surprising.

The failure is in preparation.

Not every disaster is a probability problem.

Some are decision problems.

Unknown unknowns sit beyond the tail

A tail event is still inside the distribution.

It has:

low probability

but it was represented.

An unknown unknown is different.

It may not appear in the probability model at all.

So:

TAIL RISK

means:

rare within the model.

UNKNOWN UNKNOWN

means:

absent from the model.

This distinction matters.

Extreme historical events may not repeat exactly

Suppose we have observed one enormous flood.

Should we assume the next extreme event will look identical?

Not necessarily.

The historical event provides evidence about tail behaviour.

But future extremes may differ.

Tail modelling often requires combining:

historical data,
physical understanding,
simulation.

Extreme value theory

Statistics has a field called extreme value theory.

Instead of focusing mainly on average behaviour, it studies the extremes of distributions.

For example:

maximum river levels,
peak wind speeds,
largest financial losses.

The key idea is important even without the mathematics:

Extreme events often require specialised modelling rather than simply extrapolating from the centre of the distribution.

The centre may tell us little about the tail

Suppose two rivers have:

the same average flow.

One is extremely stable.

The other experiences:

droughts,
catastrophic floods.

Average flow alone tells us little about infrastructure requirements.

We need the distribution of extremes.

Return periods

Extreme events are sometimes described using return periods.

For example:

a 1-in-100-year flood.

This does not mean:

It happens exactly once every 100 years.

It means something closer to:

Under the assumed model, there is approximately a 1% probability of exceeding that level in any given year.

Two such floods could occur in consecutive years.

"One in 100 years" is easily misunderstood

Suppose a 1-in-100-year event occurs this year.

The probability next year does not automatically become:

zero.

If the underlying distribution is unchanged, it remains around:

1%.

The phrase "return period" can create a misleading sense of schedule.

Probability has no memory in that way unless the process itself has memory.

The distribution may not be stationary

There is another problem.

A 1-in-100-year estimate often assumes:

the historical distribution remains stable.

But if:

climate changes,
land use changes,
infrastructure changes,

the probability can change.

An event historically estimated at:

1% per year

may become more frequent.

Historical return periods can become outdated.

Stationarity

A process is roughly stationary when its statistical properties remain stable through time.

For example:

mean,
variance,
tail behaviour.

Many traditional risk models assume stationarity.

But real systems can change.

This creates additional uncertainty.

Tail estimates are especially sensitive to distribution shift

Suppose average demand increases by:

5%.

That seems modest.

But perhaps the probability of exceeding capacity doubles.

Small changes near the centre can create large changes in tail probability.

This is why tail-risk management must account for evolving systems.

Thresholds turn tails into operational problems

Suppose a server has capacity:

100 requests per second.

Demand is usually:

60–80.

The tail above:

100

creates overload.

So we care about:

P(Demand > 100).

The distribution matters because the system contains a hard threshold.

Many service failures are threshold events

Examples include:

hospital demand > beds

traffic demand > road capacity

electricity demand > available supply

compute demand > servers

water demand > available supply

The service may work well until the threshold is crossed.

Then performance deteriorates rapidly.

Nonlinear consequences

Suppose a system operates at:

99% capacity.

Add another:

1% demand.

You might expect a small effect.

But perhaps queues increase dramatically.

Near capacity constraints, systems can behave nonlinearly.

Small tail events can produce disproportionately large consequences.

Queues make tails important

Suppose customers arrive randomly at a service.

If average arrival rate is comfortably below service capacity, queues remain short.

As average utilisation approaches:

100%,

waiting times can grow dramatically.

The tail of demand begins to dominate experience.

This is why shared services need spare capacity.

Utilisation and reliability trade off

A server running at:

50% average utilisation

has considerable spare capacity.

At:

99% average utilisation

it looks economically efficient.

But even small demand fluctuations can cause congestion.

So:

maximum utilisation

and:

maximum service reliability

are not the same objective.

Efficient systems can be brittle

Suppose every resource is scheduled exactly to expected demand.

There is:

zero spare capacity.

Average utilisation is excellent.

Any positive forecast error creates shortage.

This is efficient under certainty.

It is fragile under uncertainty.

Tail risk creates the need for:

reserve,
headroom,
buffers.

Buffers absorb tails

Examples include:

inventory,
spare hospital beds,
grid reserves,
backup servers,
financial capital.

Buffers look unused much of the time.

That is their purpose.

They exist for the tail.

Spare capacity is not necessarily waste

Suppose a backup generator operates only:

one hour per year.

Looking only at utilisation, it may seem inefficient.

But if that hour prevents a major blackout, its system value can be enormous.

Resources designed for rare events should not be judged only by average utilisation.

This is an important service-design principle.

Reliability is about tails

Suppose a service has:

99.9% availability.

That tells us something about tail failure probability.

But we also need to know:

are failures independent?
how long do they last?
who experiences them?

One ten-hour outage is different from ten six-minute outages even if total unavailable time is similar.

Severity and frequency

Tail risk has at least two dimensions:

frequency

and:

severity.

A system might have:

frequent small failures,
rare catastrophic failures.

Both matter.

A single average reliability metric can hide this structure.

Value at Risk

In finance, Value at Risk attempts to summarise a tail.

For example:

At the 95% level, losses should not exceed €X on most days.

This focuses on a percentile of the loss distribution.

But it has limitations.

It does not tell us how bad things become beyond that threshold.

Expected shortfall

Expected shortfall asks:

If we enter the bad tail, what is the average loss there?

This gives information about tail severity.

For example:

95% VaR

might tell us where the worst 5% begins.

Expected shortfall describes the average outcome within that worst 5%.

Different tail metrics answer different questions

We might care about:

probability of crossing a threshold,
99th percentile,
worst-case outcome,
expected loss beyond a threshold.

There is no single universal tail metric.

The right one depends on the service and consequence.

Tail probabilities can be estimated badly

Suppose we observe:

10 years of data.

An event that occurs once every:

1,000 years

probably does not appear.

We cannot estimate its frequency directly from historical counts.

Tail modelling often requires stronger assumptions.

This creates model uncertainty.

Simulation

One way to explore rare events is through simulation.

If we have a model of the system, we can generate:

many possible futures.

Perhaps millions.

Then inspect how often extreme outcomes occur.

This can reveal combinations that did not appear in the limited historical dataset.

Monte Carlo simulation

A common approach is Monte Carlo simulation.

Conceptually:

Sample uncertain inputs.
Run the model.
Record the outcome.
Repeat many times.

We obtain an empirical distribution of possible outputs.

This can help estimate:

expected values,
probabilities,
tail risk.

Simulation is only as good as the model

If the model excludes:

Scenario D,

running it a billion times will never produce Scenario D.

Simulation reduces sampling error inside the model.

It does not fix:

model misspecification.

This is crucial.

More simulation is not the same as more reality.

Stress testing complements probability modelling

Suppose a model assigns tiny probability to a particular extreme scenario.

We may still deliberately test it.

For example:

What happens if electricity demand is 30% above forecast while two major generators fail?

We do not need to know the exact probability to learn whether the system survives.

Stress testing asks:

Can the system tolerate this?

not only:

How likely is this?

Adversarial testing

AI systems can use a similar idea.

Instead of evaluating only typical inputs, deliberately search for:

unusual inputs,
edge cases,
adversarial examples.

The goal is to discover failure modes in the tail.

Testing the centre alone is not enough for high-consequence systems.

Edge cases

An edge case is an unusual situation near the boundary of expected operation.

For an autonomous vehicle:

unusual road markings,
strange vehicle configurations,
extreme weather.

For a language model:

obscure questions,
conflicting instructions,
unusual formatting.

Edge cases are often rare.

But they reveal where models break.

Tail data can be deliberately oversampled

Suppose rare failures are extremely important.

A training dataset might deliberately include more failure examples than occur naturally.

This helps the model learn.

But then:

training frequency ≠ real-world frequency.

Probability outputs may need recalibration.

Again, sampling and probability interact.

Synthetic data

If real tail examples are scarce, we may generate synthetic examples.

For example:

simulated crashes,
simulated grid faults,
generated cybersecurity attacks.

Synthetic data can expose the model to rare situations.

But the synthetic scenarios reflect assumptions in the generator.

They do not guarantee coverage of real-world extremes.

Tail performance should be measured explicitly

Suppose an AI performs:

99% accurately overall.

We may also ask:

How does it perform on the hardest 1% of cases?

Perhaps accuracy there is:

40%.

If those cases are low consequence, maybe acceptable.

If they represent critical safety events, not.

Average performance is not enough.

Worst-group performance

In fairness analysis, the "tail" may be a small population rather than an extreme numerical value.

Suppose a model works well for:

99% of users

but very poorly for a small linguistic minority.

Overall metrics may remain excellent.

The minority population lives in a performance tail.

This is one reason worst-group analysis can matter.

Tail risk can be unfairly distributed

Suppose an electricity system has only:

0.1% shortage probability.

But every shortage falls on:

the same neighbourhood.

System-wide reliability looks excellent.

Individual reliability does not.

Tail risk must be examined across people as well as across time.

Average reliability versus individual reliability

Suppose two services each fail:

1% of the time overall.

Service A

Failures are spread evenly across users.

Service B

One group experiences nearly all failures.

The system-level probability is identical.

The service experience is not.

This connects tail risk to fairness.

Rare events and human psychology

Humans are not naturally consistent about rare probabilities.

We sometimes:

ignore rare risks,
overreact to vivid rare events.

For example, a dramatic accident may feel more probable than a common but less memorable risk.

Probability helps discipline these intuitions.

Availability heuristic

The availability heuristic describes our tendency to judge events as more likely when examples come easily to mind.

After seeing dramatic news coverage of an event, we may overestimate its probability.

Rare but vivid events can dominate perception.

Probability neglect

At other times, people focus almost entirely on the consequence.

For example:

This event would be catastrophic.

and treat any non-zero probability as unacceptable.

Or they focus only on rarity:

It is extremely unlikely.

and ignore enormous consequences.

Good risk reasoning needs both:

probability

and:

consequence.

Rare events and media

Media systems have incentives to report:

unusual,
dramatic,
surprising events.

Ordinary days rarely become headlines.

Our information environment may therefore contain an oversampled tail of reality.

If we infer real-world frequencies directly from what appears in the news, our probability estimates may become distorted.

Extreme content may generate more:

engagement,
sharing,
outrage.

Recommendation systems can therefore make unusual views appear more common than they are.

The dataset we consume may be a selected sample of social reality.

This connects back to Module 2.

AI training data can overrepresent unusual content

Online text does not represent human experience uniformly.

People are more likely to write about:

unusual events,
disputes,
extraordinary experiences.

Routine experiences may go undocumented.

A model trained on public text may therefore learn a representation of the world that differs from real-world frequencies.

Frequency in text is not frequency in reality

Suppose the phrase describing a rare event appears frequently online.

That does not mean the event itself is common.

Language data captures:

what people talk about.

Not necessarily:

how often things happen.

This distinction matters when using language models to reason about real-world probabilities.

Rare events and hallucinations

Suppose an LLM is asked about an obscure fact.

There may be:

very little relevant training evidence,
several similar but incorrect patterns.

The model may generate a plausible answer.

These low-evidence regions can be thought of as part of the model's epistemic tail.

Confidence should ideally be lower there.

Long-tail knowledge

Human knowledge itself has a long tail.

Some topics have enormous amounts of data:

popular countries,
famous historical events,
common programming languages.

The long tail creates fairness problems

Suppose a language has:

billions of training examples.

Another has:

thousands.

The second sits in the data tail.

Model quality may be worse.

So tail scarcity can become unequal service quality.

This connects directly to the later fairness module.

Rare events and novelty

Something genuinely new has:

zero exact historical examples.

A new:

technology,
disease,
social behaviour

cannot be predicted by simply counting how often the exact event occurred before.

Models must generalise from related structure.

This is one limit of purely empirical frequency.

Generalisation into the tail

A good model learns relationships that extend beyond individual examples.

For example, an autonomous system may never have seen:

this exact pedestrian in this exact location.

But it has learned general patterns of:

people,
motion,
roads.

Generalisation allows prediction in new situations.

But confidence should depend on how far the new situation is from previous evidence.

Extrapolation

Prediction inside the range of observed data is called interpolation.

Prediction beyond the observed range is extrapolation.

Extrapolation is often much more uncertain.

Suppose all observed temperatures lie between:

0°C and 30°C.

Predicting at:

15°C

is interpolation.

Predicting at:

70°C

is extrapolation.

Tail predictions often involve extrapolation.

Extreme events expose models

Many models perform well in ordinary regimes.

The real test comes when the system moves outside them.

A model may appear excellent until:

demand spikes,
volatility rises,
sensors fail,
users behave differently.

Tail events reveal assumptions that the centre never tested.

Robust systems should fail gracefully

It may be impossible to predict every tail event.

So good design also asks:

What happens when the prediction is wrong?

A robust system may:

degrade gradually,
preserve essential functions,
enter a safe mode.

This is graceful degradation.

Fail-safe design

Suppose an autonomous machine becomes highly uncertain.

Instead of continuing normally, it may:

stop,
slow,
request human control.

The system is designed so that uncertainty pushes it toward a safer state.

This is fail-safe behaviour.

Not every system can simply stop

But stopping may itself create harm.

An electricity grid cannot simply:

turn everything off

whenever uncertainty increases.

A hospital cannot stop serving patients.

Shared-resource systems often need:

prioritisation,
reserves,
graceful rationing.

This connects tail risk directly to service design.

Essential versus flexible demand

Suppose electricity becomes scarce during a rare event.

A service might prioritise:

hospitals,
essential household demand

over:

flexible charging,
deferrable industrial processes.

Tail events force us to define:

what matters most when not everything can be served.

That is a societal design decision.

Tails reveal priorities

During normal conditions, almost everyone may receive what they want.

Scarcity reveals the actual rules of the system.

Who waits?

Who is curtailed?

Who gets backup?

Who pays?

Tail events therefore expose service priorities that may remain invisible under abundance.

Designing only for the average hides values

Suppose a system is optimised entirely for average efficiency.

When a rare shortage occurs, no rule has been designed for allocation.

Decisions become:

improvised,
political,
arbitrary.

Good service design includes tail behaviour in advance.

Reliability is a service choice

Suppose one service guarantees:

99% availability.

Another:

99.999%.

The second requires more:

capacity,
redundancy,
cost.

There is no free reliability.

Tail probabilities become part of the service specification.

Different services can have different tail guarantees

Not every use needs the same reliability.

For example:

Background computing job

Can perhaps wait.

Differentiated service levels can allocate scarce resilience efficiently.

Tail risk and pricing

Services with stronger tail guarantees may cost more because they require:

reserved capacity,
redundancy,
priority.

This is an important general principle:

Reliability is a resource.

It can be designed and allocated.

Insurance prices tail protection

Insurance is essentially a service for transferring tail risk.

You pay:

a predictable premium

to reduce exposure to:

a rare large loss.

The insurer pools many risks and holds resources against the tail.

This is another form of shared-resource design.

Compute systems do this too

Cloud platforms maintain:

spare servers,
replication,
failover systems.

Much of this capacity exists for:

sudden demand spikes,
hardware failures.

Average utilisation alone cannot justify it.

Tail reliability does.

Rare events and AI agents

An autonomous agent may optimise expected reward.

But if rare actions produce catastrophic losses, expected reward alone may be unsafe.

We may need:

hard constraints,
risk-sensitive objectives,
tail penalties.

This is especially important as AI systems gain greater autonomy.

Risk-sensitive reinforcement learning

Traditional reinforcement learning may maximise:

expected cumulative reward.

Risk-sensitive approaches may also consider:

variance,
worst-case returns,
probability of catastrophic outcomes.

The agent is no longer indifferent between distributions with the same expected value.

Safe exploration

An agent needs to explore to learn.

But some exploratory actions may carry unacceptable tail risk.

So:

How can a system learn without trying dangerously bad actions in the real world?

This is the problem of safe exploration.

Simulation can help.

Constraints can help.

Human oversight can help.

Rare failures need strong feedback

Suppose an AI makes:

one catastrophic error in ten million cases.

That event should not disappear into the average.

The system should learn disproportionately from severe failures.

This may require weighting examples according to consequence rather than frequency alone.

Frequency is not importance

This is a key principle.

A dataset tells us:

how often something occurred.

But system design may need to care about:

how important the outcome is.

Rare events can be:

low frequency

and:

high importance.

A learning objective based only on average frequency may underweight them.

Loss functions determine how much tails matter

Suppose a model is trained using average squared error.

Extreme errors receive larger penalties than small errors because errors are squared.

Another loss function might penalise extremes differently.

The choice of loss determines how much attention the model gives to rare large mistakes.

We will study this in Module 4.

Asymmetric tail consequences

Suppose demand prediction errors are:

Overpredict by 10%

Some spare capacity.

The numerical error magnitude is identical.

The consequence is not.

A symmetric loss may therefore be inappropriate.

This will become central when we discuss model evaluation.

Tail events should influence objectives and constraints

A service might say:

minimise average cost

subject to:

probability of catastrophic failure < 0.001%.

This separates:

ordinary performance

from:

tail protection.

That is often a better design than trying to force everything into one average objective.

The central problem

We now have three things to consider:

EXPECTED PERFORMANCE

UNCERTAINTY

TAIL RISK

A system that optimises only the first may become fragile.

A system designed entirely around the worst imaginable tail may become prohibitively expensive.

Good design balances them.

Ask questions about the tails

Whenever someone presents a probability distribution or model, ask:

What happens in the tails?
How often do extreme events occur?
How confident are we in that estimate?
Is the distribution heavy-tailed?
How much historical tail data exists?
Could correlations change during stress?
What happens when several rare events occur together?
Is the model extrapolating?
Are tail events represented in training data?
What is the consequence of a tail error?
Are safety margins sufficient?
Does the system fail gracefully?
Who bears the tail risk?
Are essential services protected?

These questions reveal what average metrics often hide.

The central idea

Most predictions concern what is likely.

Many important decisions concern what is unlikely but consequential.

The tails contain:

extreme demand,
catastrophic failures,
rare diseases,
unusual behaviours,
low-frequency AI errors.

A good probabilistic system therefore asks not only:

What is the expected outcome?

but also:

What could happen far from the expectation?

How likely is it?

How bad would it be?

How certain are we about that probability?

The progression becomes:

DISTRIBUTION

↓

CENTRE

SPREAD

TAILS

↓

EXPECTED PERFORMANCE

RARE-EVENT RISK

↓

DECISION

And at scale:

Rare does not mean negligible.

A tiny probability multiplied across millions or billions of opportunities can become a frequent real-world event.

In the next lesson, we will turn from the mathematics of rare events to the humans interpreting them:

why humans are bad at probability — how intuition can systematically misread randomness, base rates, rare events and uncertainty, and why intelligent decision systems need to account for those biases.