The four variables
Evidence, confidence, and what 'unknown' means
The fourth variable: how confident the evidence is behind the other three answers, and how to treat what is genuinely unknown.
5 min read · 4 min 50 sec film
What you'll be able to do
- Explain why evidence confidence is treated as its own variable rather than folded into the others.
- Distinguish a confirmed answer from an inferred one and from a genuinely unknown one.
- State the safer default when confidence is low.
Lesson film
Watch: Evidence, confidence, and what 'unknown' means
Three findings, one verdict, and three completely different amounts of evidence behind it — which is why confidence is a variable, not a footnote.
4 min 50 sec · 7 scenes
4 min 50 sec, narrated by your browser's voice. Captions and a full transcript are below — nothing here needs sound.
The first three variables each produced an answer: a lifetime, a harvestability judgement, a protecting mechanism.
With the player focused: Space plays or pauses, ← → seek ten seconds, Home restarts, M toggles narration.
Full transcript
1. How much to trust it
2. Three levels
3. Same verdict, different worth
4. Unknown is not safe
5. Keep the four separate
6. Date the verdict
7. Takeaway
The written lesson
The first three variables each produced an answer: a lifetime, a harvestability judgment, a protecting mechanism. The fourth variable asks how much to trust each of those answers. A confirmed observation, a reasonable inference, and a guess are not the same thing, even when they happen to point to the same conclusion.
- Confirmed — observed directly: a captured handshake trace, a verified backup retention policy, a data classification signed off by the data owner.
- Inferred — reasoned from adjacent evidence: a service is assumed to use its platform default TLS configuration because no override was found in its configuration.
- Unknown — no evidence either way. This is a legitimate answer, not a gap to paper over with an assumption.
This is also why a Mosca-style verdict, covered next, should always be dated and labeled with its confidence level rather than presented as settled fact. Confidence can change — a configuration gets confirmed, a vendor answers a questionnaire — without anything about the underlying data changing at all.
A score does not replace a threat model, missing evidence, business impact, or migration dependencies.
With all four variables defined, the next module turns them into a decision: when does a given exposure become urgent enough to act on.
| Field | Example | How it is used |
|---|---|---|
| Observed fact | One sampled origin handshake negotiated X25519 | Supports a claim about that sample |
| Planning assumption | Until tested, model unobserved peers as classical-only | Conservative prioritization, not an inventory fact |
| Confidence | Low for all other peers | Shows where investigation can change the result |
| Next action | Sample each peer class and record date | Replaces the assumption with evidence |
A current observation from one client class can be stronger than a stale vendor claim for that class yet say nothing about other clients. Record scope and date as well as confidence. If one missing fact would reverse the priority order, collecting that fact may be the most valuable next action.
Work it through
Record uncertainty without disguising it
A vendor said last year that hybrid TLS was planned. This month, one observed client connection used X25519. No other client classes were sampled.
About 5 min of unscored practice
Your task
- Record what is observed, inferred, and unknown.
- Give a temporary planning assumption and a targeted verification step.
Type here or copy the template. Your response stays in this page and is not submitted or scored.
Reveal model response and self-check rubric
A different answer can be sound when it states its assumptions and follows the evidence.
The one sampled connection negotiated classical X25519. The vendor roadmap is not a present deployment observation. Other clients remain unknown. For planning, treat unsampled connections as potentially classical-only with low confidence. Sample each material client class and the relevant server or origin hops before updating the inventory facts.
Self-check
For each point: 0 = absent or incorrect, 1 = partly supported, 2 = well supported.
- Keep observation and assumption in different fields.
- Bound conclusions to the sampled client and date.
- Name a verification action capable of changing the conclusion.
Primary reading and claim sources
Publication status checked on the date shown. Draft guidance can change.
- SP 800-30, Revision 1: Guide for Conducting Risk AssessmentsNIST · Final guidance · checked 2026-09-26
- TR 104 016: A Repeatable Framework for Quantum-Safe MigrationsETSI · Published technical report · checked 2026-09-26
Marking a lesson complete only updates this browser.