Confidence, uncertainty and language

Almost every on-chain finding beyond "this transaction happened" is an inference, and readers act on the words analysts use to express it. If an analyst writes "likely" meaning 60% and a compliance officer reads 90%, an account gets frozen on weaker grounds than anyone intended. This lesson covers how to separate what you observed from what you concluded, how to express likelihood with a defined scale, and how to state confidence and limitations for every finding.

Why words fail without a scale

The problem is old. In his 1964 essay Words of Estimative Probability, the analyst Sherman Kent described a 1951 estimate that called an attack a "serious possibility". When colleagues who had approved the text were asked what odds they had in mind, their answers ranged from about 20% to 80%. The same phrase carried opposite meanings to people who had agreed on it.

On-chain reports suffer from the same drift. Words such as "suggests", "indicates", "may", "could" and "appears" are common in tracing reports and almost meaningless: anything could be true. The fix used in professional analytic communities is a probability yardstick, a published list of terms tied to numeric ranges, combined with a separate statement of confidence.

Fact, inference, assumption and judgment

Before choosing words, sort each statement into one of four categories. The categories map neatly onto the data layers of on-chain work.

Facts need no probability word: write them as facts and cite the transaction hash and block height. Inferences need the method named. Assumptions need to be written down, because they are where reports fail: an assumption that turns out false silently invalidates every judgment built on it. Judgments carry both a likelihood term and a confidence level.

A useful habit is to make the category visible in the sentence itself: "We observed…", "This indicates, by the sweep heuristic, that…", "We assume…", "We assess that…".

Estimative language scales

Two widely cited public scales show how this is done. They are examples of practice from government analytic standards, not rules that bind anyone else: the US Intelligence Community Directive 203 (ICD 203, Analytic Standards, signed in January 2015) and the UK Professional Head of Intelligence Assessment (PHIA) probability yardstick (guidance republished in March 2025).

Points worth noticing:

• Neither scale reaches 0% or 100%. Certainties are stated as facts, not as estimates.
• The scales disagree at the edges. "Likely" covers 55–80% in one and about 55–75% in the other, and the PHIA yardstick leaves gaps between its ranges. A reader cannot know which you mean unless you say so.
• ICD 203 offers two equivalent sets of terms (the main terms and the alternatives in parentheses above, so "probable" means the same as "likely") and strongly encourages analysts not to mix the two sets in one product.

For a report, the practical rule is: pick one scale, print it in the report's method section, and use only its terms for judgments. Many teams also add the numeric range in parentheses the first time a term appears.

Confidence is not probability

Likelihood says how probable a judgment is. Confidence says how solid the basis for that judgment is. They move independently. A judgment can be "likely" with low confidence (thin evidence that happens to point one way) or "roughly even chance" with high confidence (excellent data that genuinely leaves two explanations open).

The PHIA guidance rates confidence as high, moderate or low, based on the information base, the analytical rigor applied, and the complexity and volatility of the subject. ICD 203 adds a writing rule worth copying: do not combine a confidence level and a likelihood term in the same sentence. Write them separately:

"It is very likely that bc1q…k8p0 is a deposit address of Exchange K. We have moderate confidence in this judgment: the sweep pattern is clear and the hot wallet appears in Exchange K's own published address list, but the path to bc1q…k8p0 relies on change detection across several hops."

On chain, confidence depends on:

• Data provenance: finalized blocks, a recorded node or dataset version (see Data quality, normalization and provenance).
• Method reliability: some heuristics have known failure modes (see Evaluating cluster quality).
• Independence of evidence: two methods that agree (an amount-time match and a shared gas-funding address) count for more than one method run twice.
• Label quality: self-identified service addresses beat third-party tags of unknown age.
• Remaining alternatives: if ACH left a second hypothesis standing, confidence cannot be high (see From question to hypothesis).

Uncertainty compounds along a trace

Each inferred link in a trace carries its own uncertainty, and a chain of links is weaker than its weakest member. As an illustration, suppose four successive change-detection calls are each judged about 90% reliable and treated as independent. The probability that all four are right is 0.9 × 0.9 × 0.9 × 0.9 ≈ 0.66: the end-to-end link is "likely", not "very likely", even though every individual step was "very likely". Real errors are rarely independent, so treat this as a warning about direction, not a formula.

Two practices follow. First, state likelihood for the end-to-end claim, not only for each hop. Second, look for independent corroboration that skips the chain, such as the same deposit address being funded from both ends.

Amount-and-time matching across bridges (see Cross-chain tracing) is a common source of overconfidence. Quantify it by counting how many candidates exist:

-- How unique is an amount-time match? Count candidate releases on the destination chain
SELECT COUNT(*) AS candidates
FROM bridge_releases
WHERE chain_id = 10                          -- destination chain of the bridge
  AND block_time BETWEEN TIMESTAMP '2026-03-14 10:42:00'
                     AND TIMESTAMP '2026-03-14 11:02:00'
  AND amount_eth BETWEEN 99.80 AND 100.00;   -- 100 ETH deposit minus up to 0.20 fee

The query counts releases on the destination chain within 20 minutes of the deposit and within the fee tolerance. One candidate supports a "likely" or stronger match; five candidates mean a baseline of roughly one in five before any other evidence, and the report must say so. Record the window and tolerance you used, because a wider window changes the count.

Writing limitations

Every report needs a limitations section that states what the analysis could not see and what would change the conclusions. Typical on-chain limitations:

• Coverage: chains, tokens or layers outside the scope; privacy-focused chains where amounts or links are hidden (see Other chain designs analysts meet).
• Cut-off: findings are valid up to a stated block height; funds may have moved since.
• Heuristics: each method used and its known failure modes, such as CoinJoin breaking the common-input heuristic.
• Labels: sources, dates and whether they were independently checked.
• Off-chain gaps: custodial ledgers are invisible; what happened inside an exchange is unknown without legal process.
• Absence of evidence: "no outflow observed up to block 24,812,000" is a fact; "the funds were not moved" is not.

Replace vague wording with calibrated statements:

Exam focus: the difference between fact, inference, assumption and judgment, with on-chain examples; why vague verbs ("suggests", "could") mislead, and Kent's "serious possibility" example; the ICD 203 and PHIA yardsticks as examples of practice, their ranges and their differences (no 0% or 100%, edge differences, PHIA gaps); using one declared scale; confidence versus likelihood and the rule against combining them in one sentence; what drives confidence on chain; how uncertainty compounds along a trace (0.9^4 ≈ 0.66) and counting candidates for amount-time matches; the contents of a limitations section.