← Back to Autonomy

Diagnostics · Evidence · Method

When Is the Evidence Enough?

How to tell whether your measurements can actually reach a conclusion — and what to do when they can’t, or when they disagree with each other.

Abstract

The companion post showed how to weigh messy, unequal-trust evidence into a single cause. It assumed the evidence was good enough to conclude. Often it is not. The core idea here, in plain words: more data is not the same as enough data. A thousand readings that look identical under two explanations cannot separate them. So sufficiency is never “do I have a lot?” — it is “can what I have tell my hypotheses apart, to the confidence this decision needs?” From that we build a sufficiency gate, a way to choose the single most useful next measurement, and a disciplined treatment of contradiction — with a worked EV example throughout.

§ 01 — The Wrong Question

“Do I have enough data?” is the wrong question

It feels like a question about quantity. It is really a question about whether your data can tell two stories apart.

Picture two explanations for the same fault. If every measurement you own looks the same whether explanation A is true or explanation B is true, then collecting a thousand more of those same measurements changes nothing. You do not have too little data — you have data that cannot discriminate. Conversely, a single well-chosen reading that comes out one way under A and the other way under B can settle the matter on its own.

So replace the vague question with a sharp one:

The right question

Can the evidence I have separate my surviving hypotheses, by a margin large enough for the decision I have to make? If yes, conclude. If no, the useful next step is not “collect more” — it is “collect the one thing that would tell them apart.”

Figure 1 — More of the same vs. one discriminating test
Add 1,000 more of the same H1 0.50 H2 0.50 still a coin flip — not enough Add 1 discriminating test H1 0.95 H2 0.05 separated — enough to conclude
Quantity is not the lever; discrimination is. The left posterior never moves no matter how much identical data you pour in. The right one is settled by a single measurement chosen because it reads differently under the two hypotheses.
§ 02 — Sufficiency Is Relative

Enough for what?

There is no such thing as “enough data” in the abstract. Sufficiency is always measured against three things.

The hypothesis set. Data is sufficient to separate the explanations you are currently considering. Add a new candidate tomorrow and yesterday’s sufficient data may no longer be enough — it never had to rule out that new story. This is why sufficiency is checked after framing and re-checked whenever the hypothesis list changes.

The confidence bar. How sure do you need to be? That is set by the cost of being wrong, and you should set it before looking at the data. Replacing a $12 sensor needs a low bar; pushing an over-the-air change to a safety system, or scrapping a production lot, needs a high one. The same evidence can be “enough” for the cheap decision and “nowhere near enough” for the expensive one.

The trust of the sources. A margin built from one shaky sensor is not the same as the same margin built from three independent, high-trust signals. As in the prequel, what counts is trust-weighted, independent evidence — not raw counts.

One line to remember

Evidence is sufficient when it separates these hypotheses, by this margin, using sources you trust — for a bar you fixed by the cost of being wrong, before you peeked.

§ 03 — The Sufficiency Gate

Four checks before you are allowed to conclude

Bundle the idea into a gate the conclusion must pass. Fail any check and you are not done — but you learn exactly why, which tells you what to do next.

Figure 2 — The sufficiency gate
fused posterior 1 DISCRIMINATE can it tell apart? 2 MARGIN big enough lead? 3 COVERAGE nothing unexplained? 4 ROBUST survives -1 clue? PASS ALL → CONCLUDE FAIL ANY → not enough yet: the failed check says what to collect (§05) or re-audit (§07)
The gate is diagnostic about itself. Each failure points at its own fix: fail discrimination, you need a separating measurement; fail margin, you need more weight; fail coverage, a hypothesis is missing; fail robustness, you need independent corroboration.

Written as code, the gate returns not just yes/no but which exit you are taking and what to do about it.

Algorithm 1sufficiency_check(H, E, bar)

input H surviving hypotheses · E evidence · bar required confidence

output CONFIRMED · INCONCLUSIVE(next) · INCOHERENT(reason)

if high_trust_conflict(E): return INCOHERENT("sources disagree") # §07

P posterior(H, E)

if margin(P) < bar: # checks 1 & 2

t next_measurement(H, E) # §05 value of information

return INCONCLUSIVE(t)

if orphan_anomalies(top(P), E): # check 3: coverage

return INCONCLUSIVE("re-frame: add a hypothesis")

if not survives_leave_one_out(top(P), E): # check 4: robustness

return INCONCLUSIVE("corroborate with an independent source")

return CONFIRMED

§ 04 — Telling Hypotheses Apart

Two suspects, one alibi

The first and most important check. If two explanations make the same prediction on every sensor you have, no amount of that data will choose between them.

Engineers call this observational equivalence; a detective would call it two suspects with the same alibi. The cure is a discriminating measurement — a single observation the two suspects do not share.

The running example

An EV throws a “reduced power” warning that shows up only under hard acceleration. The high-trust evidence on hand: the warning’s freeze-frame and a CAN log showing the pack terminal voltage sags when current is high. Two explanations survive the referee:

H1 · High-resistance HV connector

a loose / corroded busbar drops voltage at the connector under high current

Predicts: terminal voltage sags under load.

H2 · Weak cell module

one aging module collapses inside the pack under load at low charge

Predicts: terminal voltage sags under load.

Both predict exactly what we measured. On the data we have, they are indistinguishable — the sufficiency gate fails at check 1.

Figure 3 — Observational equivalence
H1 · bad connector drop at the connector H2 · weak module drop inside the pack terminal voltage sags under high current (the only signal we have) same fingerprint → can’t tell apart
Two arrows into one box. When different causes produce the identical reading on your available sensors, the data is structurally insufficient. The answer is not more drive logs — it is a different sensor.
§ 05 — Which Test Next?

Spend your next measurement where it pays

If you must collect one more thing, collect the thing that shrinks your uncertainty the most. That idea has a name: value of information.

List the measurements you could take. For each, ask: how differently would it read under the surviving hypotheses, and how much would that split the posterior? The best test is the one that, on average, leaves you most certain afterward. In plain terms — pick the question whose answer you genuinely can’t predict, because that is the one that carries the most information.

Figure 4 — Ranking candidate tests by information gain
expected information gain (bits) — higher is better module voltages under load 0.92 connector temperature under load 0.55 inverter temperature 0.20 another hard-acceleration log 0.03 “more of the same” (bottom) is near-worthless; the module-voltage test (top) wins
Not all measurements are equal. Another drive log repeats what you know (0.03 bits). Measuring voltage at the module level is the one signal that reads differently under H1 and H2, so it carries the most information — collect that.
Algorithm 2next_measurement(H, candidate_tests)

input H hypotheses with current posterior · candidate tests T

output the single most informative test to run next

for t in T:

before uncertainty(posterior) # e.g. entropy of P(H)

gain[t] before − expected_uncertainty_after(t) # avg over t’s outcomes

return argmax gain[t] # break ties by cost / time / risk

We collect the module voltages. Now the two suspects part ways — because they make different predictions about this sensor:

Figure 5 — The discriminating measurement splits the posterior
measure module voltages under load drop at connector, modules OK → supports H1 one module collapses, connector OK → would support H2 observed: drop localized at the connector H10.94 H20.06
One sensor, both stories tested at once. Because module voltage is predicted to differ between H1 and H2, its actual reading (drop at the connector) drives the posterior to a clear lead. The gate’s discrimination check now passes.
§ 06 — Margin, Coverage, Robustness

The other three checks

Discrimination got us a leader. Three more checks decide whether the lead is trustworthy enough to act on.

Margin — is the lead big enough?

Look at the gap between the top hypothesis and the runner-up, and remember §02: the gap must clear the bar set by the cost of being wrong, and it must be carried by high-trust, independent evidence. A 0.55-to-0.45 split is a leader in name only. A 0.94-to-0.06 split built on one good measurement plus the referee is a real one.

Coverage — is anything left unexplained?

A sufficient explanation accounts for all the salient facts, not just the convenient ones. If your winning cause explains the voltage sag but leaves a second symptom — say, the warning also appearing once on a cold morning at full charge — then you have an orphan anomaly. That is a warning sign: either the cause is wrong, or a second fault is present and you have only found one. Unexplained leftovers mean re-frame, not conclude.

Robustness — does it survive losing its best clue?

Ask the uncomfortable question: if my single most influential piece of evidence turned out to be wrong, would the verdict still stand? If everything hinges on one sensor that could be miscalibrated, you have a single point of failure dressed up as a conclusion. “Rich enough” means the answer survives a leave-one-out.

Figure 6 — Leave-one-out: robust vs. fragile
ROBUST case all evidence 0.94 minus best clue 0.87 ✓ holds FRAGILE case all evidence 0.92 minus best clue 0.41 ✗ collapses a verdict that depends entirely on one clue is not yet sufficient — corroborate it
Redundancy is what makes data “enough.” Pull the most influential clue. If the verdict barely moves (top), you have independent support. If it collapses (bottom), you have a single point of failure — get one more independent line before you act.
§ 07 — When Sources Disagree

Contradiction is information, not noise

The instinct when two clues clash is to average them or pick the one you like. Both are wrong. A contradiction is a clue in its own right — it is telling you something specific.

Work through it in order:

First, does the trust hierarchy already settle it? If a high-trust source disagrees with a low-trust one — a freeze-frame against a vague customer report — there is no real conflict. The grade decides; keep the higher-trust signal and move on. Most “contradictions” dissolve right here.

If two high-trust sources clash, that is a real alarm. Two things you both trust cannot both be right. The most likely explanation is not that physics broke — it is that one of them is not what you think it is: a sensor is faulty, the firmware on the car is not the version in the repo, or two readings were taken at different points or different times (a provenance mismatch). Treat a high-trust conflict as a provenance bug until proven otherwise, and go re-audit. Resolving it usually is a finding.

If nothing fits well — support scattered across everything — the true cause is missing. When no hypothesis gathers real weight and the evidence pulls in all directions, the lesson is not “pick the least-bad option.” It is that your list is incomplete. Go back and frame a new candidate.

Figure 7 — Handling a contradiction
conflict detected both sources high-trust? (equal grade?) NO trust hierarchy resolves keep the higher-trust source YES re-audit provenance a trusted source is wrong/mismatched nothing fits well? → missing hypothesis → re-frame
Never average a contradiction. Resolve it by finding why the sources disagree. That search almost always ends in a real discovery — a bad sensor, a mislabeled log, or a cause you had not yet imagined.
Plain-words version of “conflict mass”

Formal evidence theory measures how much of your belief lands on combinations that cannot all be true. A lot of that “conflict mass” is a mathematical way of saying the same thing: your sources disagree more than chance allows, so stop combining and start questioning — either a source is corrupt, or the right answer is not on your list yet.

§ 08 — Three Ways to Stop

Confirmed, inconclusive, or incoherent

A diagnosis procedure that can only output “here is the answer” will lie to you when it has to. A good one can end in three honest states.

Figure 8 — The three exit states
surviving hypotheses + fused posterior SUFFICIENCY GATE CONFIRMED passes all checks → report & act INCONCLUSIVE can’t separate / thin margin → collect next measurement INCOHERENT high-trust conflict / nothing fits → re-audit or re-frame new measurement re-enters the loop re-framed hypothesis re-enters
Two of the three exits are loops, not dead ends. Inconclusive sends you to collect the one measurement that helps (§05); incoherent sends you to fix a source or add a hypothesis (§07). Only Confirmed leaves the loop.

The EV example, all the way through

Pick up where §05 left off: the module-voltage test localized the drop to the connector, pushing H1 (bad connector) to 0.94. Discrimination passed. Then a contradiction appears.

The clash

two high-trust signals disagree

Voltage localization says the loss is at the connector (→ H1). But the connector temperature log reads cool — and a high-resistance joint passing 142 A should get hot. Two trusted readings, opposite stories.

The re-audit (§07)

provenance, not physics

Following the high-trust-conflict rule, we check provenance. The temperature probe is mapped to the wrong connector, and its sample was logged at key-off, not under load. The reading was never measuring the suspect joint.

The resolution

the conflict became a finding

Re-measure the correct joint under load: it runs hot. The contradiction is gone, and it added an independent line of support for H1. Now two unrelated signals — voltage localization and temperature — agree.

Run the final gate. Discrimination: passed (module test). Margin: 0.96, high-trust. Coverage: explains the sag, the load-only timing, and the heat. Robustness: survives leave-one-out, because voltage and temperature are independent. Conflict: resolved. The procedure exits at Confirmed.

Verdict

confirmed cause · with its kill-switch

A corroded high-voltage busbar connector raises resistance, dropping voltage and tripping the reduced-power limit under high current. Disconfirming test: clean and torque the joint — if the voltage drop and heat vanish, confirmed; if they persist, re-open H2.

And the honest counterfactual: had the re-audit found the temperature probe correct and the joint genuinely cool, with modules also fine — nothing fitting — the procedure would have exited at Incoherent and sent us back to frame a new hypothesis (a failing inverter stage, perhaps), not forced a false verdict.

Part II — The Math, Made Concrete

Putting numbers under the figures

Part I built the intuition with illustrative bars. Here we show the actual arithmetic — a real Bayesian update, the entropy that defines “information,” the sequential test that says stop now, and the cost rule that says stop collecting. Everything below is reproducible by hand.

§ 09 — The Numbers Behind the Figures

A real Bayesian update, and where “bits” come from

The posteriors and the information-gain bars in Part I were round numbers for the eye. Here is the calculation that actually produces them, on the EV example.

Step 1 — the update

Before the module-voltage test, the two suspects are tied: prior P(H1) = P(H2) = 0.5. The test can come out two ways — the drop is localized at the connector (call it Dₜ, favouring H1) or at a module (favouring H2). From bench data we know the test is reliable but not perfect:

P(Dₜ | H1) = 0.9    and    P(Dₜ | H2) = 0.1

We run it and observe Dₜ (drop at the connector). Bayes’ rule just normalizes prior × likelihood:

Table 1 — Bayes update for the module-voltage test
HypothesisPriorLikelihood P(Dₜ|·)Prior × LikPosterior
H1 · bad connector0.500.900.4500.90
H2 · weak module0.500.100.0500.10
total1.000.5001.00
One observation, 0.5 → 0.90. The likelihood ratio is the engine: 0.9 / 0.1 = 9. With even prior odds (1:1), the posterior odds are 9:1, i.e. P(H1) = 9/10 = 0.90.

The shortcut worth memorizing is the odds form, because it makes combining evidence trivial: posterior odds = prior odds × likelihood ratio. If an independent second clue — the connector running hot — carries a likelihood ratio of 4, you just multiply:

odds = 1 × 9 × 4 = 36 → P(H1) = 36 / 37 ≈ 0.97

That multiplication is only valid if the two clues are independent given the hypothesis — the same rule that stopped us double-counting ten echoing complaints in the prequel. Correlated evidence does not multiply.

Step 2 — where the “bits” come from

Uncertainty is measured with Shannon entropy, H = −Σ p·log₂(p). A 50/50 split is maximum confusion — exactly 1 bit. After the test pushes us to 90/10, the confusion drops to 0.47 bit. The information gain of the test is the difference.

Worked computationentropy & information gain

# before the test — total confusion

H_before = -(0.5·log₂0.5 + 0.5·log₂0.5) = 1.00 bit

# after observing Dₜ — posterior 0.90 / 0.10

H_after = -(0.9·log₂0.9 + 0.1·log₂0.1) = 0.137 + 0.332 = 0.47 bit

information gain = 1.00 - 0.47 = 0.53 bit # this is the VoI number

Figure 9 — Uncertainty before and after the test
before (50/50) 1.00 bit after (90/10) 0.47 bit gain = 0.53 bit a test’s “value of information” is exactly this shrinkage in entropy, averaged over its possible outcomes
This is what the §05 bars meant. The illustrative chart used round figures; the real ranking is computed this way — each candidate test’s bits are the expected entropy it removes. A test that can’t change the split removes nothing.
§ 10 — Stop When It’s Enough

The sequential test: let the evidence decide when to stop

Instead of fixing how many measurements to take in advance, take them one at a time and stop the moment the running total of evidence is decisive. This is Wald’s sequential probability ratio test — the cleanest formal answer to the title question.

Keep a running tally of the log-likelihood ratio: every new measurement adds log[ P(data|H1) / P(data|H0) ] to the total. Evidence for H1 pushes the tally up; evidence against pushes it down. Set two lines:

The beauty is that the thresholds are set directly by the error rates you will tolerate — A = log((1−β)/α), B = log(β/(1−α)) — so “enough” is defined by the risk you accept, exactly as in §02. A cheap decision uses tight thresholds and stops early; a safety-critical one uses wide thresholds and demands more.

Figure 10 — The evidence as a random walk between two thresholds
A — accept H1 (fault confirmed) B — reject H1 (no fault / other cause) 0 cumulative log-LR evidence accumulated → still wandering: not enough yet crosses A → decide, stop
“Enough” is a crossing, not a count. Each measurement nudges the tally. The orange walk gathers enough one-directional evidence to cross the upper line and stops early; the grey one keeps wavering — genuinely inconclusive, and the test refuses to pretend otherwise.
Algorithm 3sequential_test(stream, A, B)

input stream of measurements · thresholds A > 0 > B (from α, β)

S 0 # running log-likelihood ratio

for each measurement x:

S S + log[ P(x|H1) / P(x|H0) ]

if S ≥ A: return ACCEPT_H1 # enough — fault

if S ≤ B: return REJECT_H1 # enough — not this

return KEEP_SAMPLING # still between the lines

§ 11 — When to Stop Collecting

Stop measuring when the next test isn’t worth it

The sequential test stops when the evidence is decisive. But sometimes it never gets decisive — and chasing certainty has a price. The second stopping rule weighs the value of the next measurement against its cost.

Every candidate test has a value (its information gain, from §09, converted into how much it reduces your expected loss) and a cost (time on the lift, a teardown, a customer kept waiting, the risk of the test itself). The rule is simple:

The cost-aware stopping rule

Keep collecting while the best remaining test’s value of information exceeds its cost. Stop when even the most useful test left costs more than it would save — and decide now, on the current best hypothesis, accepting its residual risk.

Two forces work against each other. Each test you run leaves the next one with less to add — diminishing returns — so value falls as you go. Cost, meanwhile, holds steady or rises (the cheap tests get used up first). Where the curves cross is where you stop.

Figure 11 — The stopping point: value vs. cost
value / cost measurements collected → COLLECT (value > cost) STOP & DECIDE value of next test cost of next test stop here
Certainty has a budget. Left of the crossing, the next test pays for itself — collect it. Right of it, you are spending more than the answer is worth; commit to the leading hypothesis and carry its residual uncertainty forward (the inconclusive-but-act case).
Algorithm 4cost_aware_stop(H, tests)

loop:

if sufficiency_check(H, E, bar) = CONFIRMED: return decide(H)

t* next_measurement(H, tests) # most informative remaining (§05)

if value(t*) ≤ cost(t*): # not worth it

return decide_under_uncertainty(top(H)) # stop, act on best

E E + collect(t*); tests tests − t*

Together the two rules cover both ways an investigation ends well: the sequential test stops you the instant the evidence is conclusive, and the cost rule stops you when conclusiveness is no longer affordable. Neither lets you drift — collecting data forever because you are afraid to decide.

§ 12 — Practical Notes

Field rules of thumb

The method in habits you can carry into the bay.

1
name it first

Name the discriminating measurement before collecting more data

If you cannot say which single observation would change your mind, you are not ready to collect — or to conclude. The question comes before the data.

2
set the bar early

Fix the confidence bar before you look

Decide how sure you must be from the cost of being wrong, in advance. Setting the bar after seeing the data is how motivated reasoning sneaks in.

3
different, not more

Collect the one different thing, not more of the same

Ten more identical logs move nothing. One orthogonal sensor can settle it. Spend the next measurement where the information is.

4
conflict = bug

Two trusted sources disagreeing is a provenance bug until proven otherwise

Don’t average it away. Check wiring, sensor mapping, firmware version, and when/where each reading was taken. The mismatch is usually the discovery.

5
nothing fits

“Nothing fits” means a missing hypothesis

A flat, scattered posterior is not bad luck — it is a signal the true cause is not on your list. Re-frame instead of forcing a choice among the wrong options.

6
inconclusive is a result

Report “inconclusive” with a shopping list

If you cannot conclude, say so — and name the exact measurement that would. That is a useful, honest deliverable, not a failure.

7
pull a clue

Stress-test by removing your best evidence

If the verdict collapses without one clue, you have a single point of failure. Corroborate before you act on anything expensive.

8
design for it

Sufficiency is cheaper to build in than to chase

The best time to guarantee you can tell faults apart is at design — sensor placement and testability analysis. Diagnosability is a property you can engineer, not just hope for.

§ 13 — References & Further Reading

Where these ideas come from

The method braids together a few well-established lines of work. Good entry points, grouped by the question they answer.

When is the evidence enough? (stopping & uncertainty)

A. Wald, Sequential Analysis (1947). The sequential probability ratio test — keep sampling only until the evidence ratio crosses a threshold. The original formalization of “stop when it is enough.”

C. E. Shannon, “A Mathematical Theory of Communication” (1948). Entropy as the measure of uncertainty that “margin” and “information gain” in this post are built on.

Which test next? (value of information & experimental design)

R. A. Howard, “Information Value Theory” (1966). The formal value of information: what a measurement is worth before you take it.

D. V. Lindley, “On a Measure of the Information Provided by an Experiment” (1956). Information gained from an experiment; the foundation of Bayesian optimal experimental design.

K. Chaloner & I. Verdinelli, “Bayesian Experimental Design: A Review” (1995). A readable survey of how to choose the most informative experiment.

Telling hypotheses apart (diagnosability & identifiability)

M. Blanke, M. Kinnaert, J. Lunze, M. Staroswiecki, Diagnosis and Fault-Tolerant Control (Springer). Structural diagnosability and fault isolability — exactly when a set of measurements can or cannot separate given faults.

L. Ljung, System Identification: Theory for the User. Identifiability: the conditions under which data can actually pin down what you are trying to estimate.

Handling conflict (consistency-based diagnosis & evidence theory)

R. Reiter, “A Theory of Diagnosis from First Principles” (1987). Diagnoses as explanations consistent with the observations; the formal idea of a “conflict” set.

J. de Kleer & B. C. Williams, “Diagnosing Multiple Faults” (1987). Generating candidates from conflicts, and reasoning about more than one fault at once.

G. Shafer, A Mathematical Theory of Evidence (1976). Belief functions and the notion of conflict mass when independent sources disagree.

Foundations of the reasoning

P. Lipton, Inference to the Best Explanation (2004). The philosophy of abduction the whole diagnostic method rests on.

K. Ishikawa, Guide to Quality Control. The practical, shop-floor side: cause-and-effect (fishbone) analysis and disciplined root-cause work.

A note on these references

These are entry points to large literatures, cited for orientation rather than as the specific source of any single claim here. Titles and years are given so you can find them; consult the originals for exact statements.

§ — The Series

The Diagnosis Series

Nine connected parts, from one car’s evidence to a fleet campaign and back to prevention. See the full map & reading guide →

1

Root-Cause Analysis Under Uncertain, Heterogeneous Evidence

Grade, anchor, and fuse messy, unequal-trust clues into one cause.

2

When Is the Evidence Enough?  you are here

The sufficiency gate, value of information, and handling conflict.

3

Harder Cases in Diagnosis

Multiple faults, intermittency, and lying sensors.

4

Fleet-Scale Root-Cause Analysis

One code across a population: de-mix, stratify, remediate.

5

Fleet RCA, Made Rigorous

Significance, surveillance, forecasting, closing the loop.

6

Proving Cause with Experiments

Turn observation into proof with staged rollouts.

7

Diagnosis on the Vehicle

Real-time fault detection at the edge, feeding the fleet.

8

The Data Plumbing Behind Fleet Diagnosis

Joining, aligning, and cleaning the data that makes it work.

9

From Root Cause to No Cause

Prevention and the corrective-action loop — engineer it out.