That's the most common mistake people make with probabilities: rounding them into certainties. Engineers deal with this constantly. Uptime, error rates, test flakiness, model confidence. So let's read "73%" the way we'd read any other metric: carefully, with units, and with a test.

73% is a frequency, not a feeling

The cleanest interpretation: if you collected many situations where this source says 73%, about 73 out of 100 would come true. That means 27 would not. Not "a few unlucky exceptions," but more than one in four.

If your service had a 27% failure rate, you'd page someone. Yet when a forecast says 73%, we often treat the other 27% as negligible.

One outcome can't judge a probability

If a 73% event doesn't happen, the forecast wasn't necessarily wrong. A single outcome tells you almost nothing about whether the number was good. You need many forecasts from the same source to judge it, exactly like you need many requests to estimate latency percentiles.

Here's a quick way to feel that in your gut:

import random

def run(p=0.73, trials=10, experiments=100_000):
    """How often does a 73% event happen k times out of 10?"""
    counts = [0] * (trials + 1)
    for _ in range(experiments):
        k = sum(random.random() < p for _ in range(trials))
        counts[k] += 1
    for k, c in enumerate(counts):
        bar = "#" * int(60 * c / experiments)
        print(f"{k:2d}/10  {c / experiments:6.3f}  {bar}")

run()

Output (roughly): the most likely result is 7 out of 10, but 5 or 6 out of 10 is common, and even 4 out of 10 shows up. Ten tries of a perfectly correct 73% forecast can easily look "wrong."

Ask three engineering questions

When you see a probability, interrogate it like a metric:

1. What's the reference class? 73% of what? Elections in this country? Product launches by this team? Probabilities are only meaningful relative to a set of similar cases.
2. What's the track record? Has this source been calibrated before? A forecaster with a history of "73% → happens 73% of the time" deserves trust; one without a history deserves curiosity.
3. How fresh is it? A probability is a snapshot. Like a cached value, it goes stale when the world changes.

Compound probabilities sneak up on you

Engineers know this from reliability: chain five components that are each 99% available and you get about 95%. The same happens with forecasts.

steps = [0.9, 0.85, 0.8, 0.9]
total = 1.0
for p in steps:
    total *= p
print(f"All steps succeed: {total:.2%}")  # ~55%

Four things that each look "likely" combine into a coin flip. Most project plans are secretly this math, which is why "everything just has to go right" is a warning, not a plan.

Write probabilities like log lines

A habit worth stealing: when you make a forecast, record it like a structured log entry with timestamp, statement, probability, and resolution date. Later you can query it, bucket it, and compute calibration, exactly like any other telemetry.

The takeaway

"73%" is not "yes." It's "yes, about three times in four, and I expect to be wrong roughly once in four." Reading probabilities like an engineer means respecting the failure rate, demanding a track record, and remembering that one outcome is a sample size of one.

Next time you see a confident number on a screen, ask it for its error bars.