Explaining Uncertainty, Error, and What the Model Cannot Do

Most conflict between technical teams and stakeholders traces to a single mismatch that is rarely made explicit.

The stakeholder's mental model, usually formed from ordinary software, is that systems are correct. A payroll system that computed the wrong salary would be a bug, reported and fixed. Correctness is the default and errors are defects.

A statistical system does not work that way. It is wrong a certain proportion of the time by design, that proportion is a property rather than a fault, and a specific wrong answer is usually not fixable in isolation. You can shift the rate, and you generally trade one kind of error for another.

When those two models meet without being reconciled, the sequence is predictable. The system is deployed. It makes a mistake. Someone reports it as a bug. The technical team explains that it has a known error rate. The stakeholder hears an excuse, because in their model errors are defects and this sounds like refusing to fix one. Confidence drops sharply, and it drops on the basis of a single case rather than the aggregate performance everyone agreed was acceptable.

That sequence is not caused by the error. It is caused by the error being the first time the stakeholder encountered the probabilistic nature of the thing.

So the highest-value communication in a technical project happens before deployment, and it is the subject of this lesson: making the error rate concrete, agreed, and emotionally absorbed while nothing is going wrong.

A stakeholder who has already looked at examples of the mistakes it will make reacts to the first real one completely differently from one who has not.

The single most useful thing to communicate about any classifying system is that it makes two different kinds of error with different consequences, because that reframes the whole conversation from accuracy to trade-off.

It can flag something that is fine, which produces wasted work, an inconvenienced customer, and eroded trust in the alerts.

Or it can miss something that is not fine, which produces the loss the system existed to prevent.

Those have completely different costs, and the relative cost is a business judgement rather than a technical one. In fraud detection, missing a fraud costs money and a false alarm costs a customer's afternoon. In medical screening, the asymmetry is enormous and runs the other way. In content moderation, both directions are reputationally expensive in different ways.

Why this is the most valuable thing to explain. It hands the stakeholder a decision that is genuinely theirs, and it converts an argument about whether the model is good enough into a conversation about where the threshold should sit.

And the trade-off is real rather than rhetorical. Catching more of what you are looking for means accepting more false alarms; reducing false alarms means missing more. There is no setting that improves both, which is the fact stakeholders most need and least expect.

How to present it usefully. Give the two rates in units of consequence rather than as metrics. At this setting we catch about nine in ten fraudulent applications and wrongly flag about two hundred legitimate ones a month for review. At a stricter setting we catch nineteen in twenty and wrongly flag six hundred.

That framing lets a stakeholder choose, and choosing is what makes them an owner of the outcome rather than a critic of it.

The same performance, expressed four ways, in increasing order of usefulness to a stakeholder.

As a metric name. Precision is 0.82, recall is 0.91. Meaningless to almost everyone, including many people who will nod at it.

As a percentage in plain terms. It catches about ninety percent of cases and about eighteen percent of its alerts are false alarms. Better, and still abstract, because percentages of an unstated base do not translate into anything.

As frequencies over a real period. Out of roughly a thousand applications a month, it will flag about a hundred and twenty. Around a hundred of those are genuine and about twenty are not. It will also miss around ten genuine ones. Now the stakeholder can picture the work.

As consequences. Your team reviews about a hundred and twenty cases a month instead of a thousand. Roughly twenty of those reviews will turn out to be nothing. About ten frauds get through, which at your average value is this much money.

The fourth version is what allows an actual decision, and note what it required: knowing the volume, the team's capacity, and the value at stake. Those are things the stakeholder knows and you have to ask for.

Which is the general lesson. Translating performance into consequences is not a presentation skill. It requires business information, and asking for it is itself the collaborative act that makes the number meaningful.

The most effective single practice in this lesson, and it is almost never done.

Before deployment, sit with the stakeholders and go through actual examples of the system's mistakes. Not the error rate. The specific cases, with the real records, where it got it wrong.

Why this works so much better than any explanation of statistics.

It makes the abstraction concrete. Ten percent error is a number people agree to without absorbing. Twenty actual cases they can read is an experience.

It surfaces whether the errors are acceptable in kind rather than in quantity. A stakeholder frequently discovers that a particular sort of mistake is unacceptable regardless of how rare it is, which is a requirement nobody had stated because nobody had seen it. That is a finding worth far more than a percentage point of performance.

It reveals domain knowledge you did not have. Domain experts looking at errors say things like these are all from the same region, or these all came through the partner channel, which frequently identifies a real problem in the data.

And it distributes the decision. A stakeholder who has looked at the mistakes and agreed to proceed responds to the first live error as something anticipated rather than as a betrayal.

That last effect is the one that protects the project. The difference between we knew this would happen and I was told this worked is the difference between an adjustment and a loss of confidence.

The practical version. Sample thirty errors, including both kinds. Sit with the people who will live with the system. Read them together. Ask which of these matter and which are fine. Then set the threshold from that conversation rather than from a metric.

The question that arrives constantly after deployment: why did it do that for this specific case. It deserves an honest answer, and honesty here is more nuanced than either yes or no.

What is genuinely available. For many model types you can identify which inputs pushed a particular case toward its outcome. That is real information and it is useful for checking whether the system is keying on something sensible.

What it is not. A causal explanation of the model's reasoning, because in most cases there is no reasoning to report. Attribution methods describe which features the output was sensitive to, which is a different claim, and the catalogue's explainability material covers why these methods have known limitations and can be misleading.

How to answer the question without overclaiming.

Say what influenced the outcome, in the domain's terms. This application was flagged mainly because the address had changed recently, the device was new, and the amount was unusual for this account type.

Say what that is and is not. Those are the factors it weighted most, which is not the same as a reason, and the system does not reason in the way a person would.

And offer the check that matters. If this looks wrong to you, that is worth knowing, because a pattern of cases that domain experts consider wrong is the strongest signal that something is off.

What to avoid. Constructing a narrative that sounds like reasoning, because it will be quoted back as the system's justification, potentially to a customer or a regulator. And dismissing the question as unanswerable, which reads as evasion and is not quite true.

Where a decision affects someone significantly, there may be a legal requirement to provide meaningful information about the logic involved, which makes this a compliance matter rather than a courtesy.

Technical teams are regularly asked for things that will not work, and how that is refused determines whether they are consulted next time.

The requests that need refusing. Predicting something the data cannot support. Building on data that does not exist or is not reliable. Achieving a performance level the problem does not permit. Attributing a cause from observational data. And automating a decision that should not be automated.

Why refusals go badly. The technical answer is usually correct and delivered in a way that sounds like unwillingness, or is buried in method the stakeholder cannot evaluate. What they hear is the team saying no with jargon, which produces a search for someone who will say yes.

What works better.

Separate cannot from should not, because they are different conversations. We do not have the data is a resource problem with a possible solution. This would be unfair to customers is an objection that needs to be made in those terms rather than dressed as a technical limitation.

Give the reason in their terms. We have never recorded why customers left, so there is nothing to learn the pattern from lands where the data lacks the target variable does not.

Offer the nearest thing that would work. Almost every impossible request has a possible neighbour. We cannot predict who will churn, and we can tell you who has stopped using the product, which is often what they wanted.

Say what it would take. If you want this, we would need to start recording this now, and we would have a usable signal in about six months. This converts a refusal into a plan and it frequently gets funded.

And be clear about confidence. We could build something and I do not think it would be reliable enough to act on is more useful than a flat no, because it lets them weigh it.

A team known for refusing badly stops being asked, and the requests do not stop; they go somewhere with less judgement.

A conversation that is always uncomfortable and always worse for having been deferred: telling stakeholders that a working system is no longer working.

Why it happens at all is worth explaining to stakeholders in advance, because it is genuinely counterintuitive. A model learns patterns from historical data, and the world changes: customer behaviour shifts, a competitor launches, a process changes upstream, the population moves. The model has not broken. The world stopped matching it.

That framing matters, because degradation reads to a stakeholder as a defect that should have been prevented, and it is closer to a machine needing maintenance.

What to establish before deployment.

That performance will decline, as a normal property rather than a risk.

That you will monitor it, and what will be monitored.

What threshold triggers action, agreed in advance while nobody is defensive.

And who is told, and when.

Why agreeing the threshold in advance matters so much. Once performance is falling, every conversation about whether it is bad enough to act is contaminated by the fact that acting is expensive and someone owns the project. A number agreed while everything was fine removes that argument entirely.

How to deliver the news when it comes. Early, before someone else notices. With what changed rather than only that it changed. With what you propose and what it costs. And without defensiveness, because degradation is not a failure of the original work and treating it as one encourages hiding it.

The general principle for anyone running technical systems. A team that reports its own systems degrading, before being asked, builds far more credibility than one whose systems never appear to have problems. The second team is not doing better work; it is monitoring less or saying less.

Collected into things to do rather than things to know.

Reconcile the mental models before deployment, explicitly. Statistical systems are wrong a proportion of the time by design, that proportion is a property rather than a defect, and a stakeholder meeting this idea for the first time via a live error will lose confidence disproportionately.

Explain the two kinds of error and their trade-off, because it converts an argument about quality into a decision that is legitimately theirs. There is no setting that improves both, and stakeholders need that fact.

Give numbers as consequences over a real period, not as metrics. Doing so requires volume, capacity and value figures you have to ask for, and asking is itself useful.

Show thirty actual errors before deployment and go through them together. This is the highest-value practice in the lesson: it makes the rate concrete, surfaces unacceptable error types nobody had specified, extracts domain knowledge, and distributes ownership of the decision.

Answer why did it do that with the factors that influenced it, labelled as factors rather than reasons, and never construct a narrative that sounds like reasoning.

Refuse requests by separating cannot from should not, giving the reason in domain terms, offering the nearest possible thing, and saying what it would take.

Agree the degradation threshold before deployment, and report degradation before anyone asks.

And the idea underneath all of it. Every practice here moves a conversation earlier, from after something goes wrong to before it does. The content is the same; the timing is what determines whether it is received as information or as an excuse.