Feynman Technique

Activate when: user says 'explain this simply', 'teach me like I'm five', 'do I really understand this', 'what's the simplest way to think about X', 'what's missing in my model', wants to test genuine vs. surface understanding of a concept, or is preparing to teach/present and needs to verify their mental model. Do NOT activate when: user needs a fast decision on a concept already well-tested, or the concept is irreducibly formal (legal statutes, certain proofs) where simplification destroys essential content.

Overview

The Feynman Technique tests whether understanding is genuine (can reproduce, predict, extend) or surface (can recognize, recall jargon). It exploits a cognitive asymmetry: recognizing an explanation is much easier than reproducing it. Feynman's principle: "The first principle is that you must not fool yourself — and you are the easiest person to fool."

Compose with neighbors: first-principles supplies the ground-level understanding Feynman Technique then tests. metacognition monitors your thinking process; Feynman Technique stress-tests the output. critical-thinking evaluates someone else's claimed understanding.

When to Use

• Need to know whether understanding is genuine vs. surface; preparing to teach or make a high-stakes decision; a model is giving wrong predictions
• Someone says: "explain it simply," "teach me like I'm five," "do you really understand this," "what am I missing?"

When NOT to use: Fast decision on a concept already tested; concept too new with no source material for Step 3; concept irreducibly formal — use first-principles instead; evaluating creativity or judgment, not understanding.

Coaching Novices (Adaptive Front Door)

• Engine mode: user has a specific concept to test → run The Process directly.
• Coach mode: user is unfamiliar or has no concrete case → guide step by step.

In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.

1. What it is. The Feynman Technique is an understanding test: explain a concept in plain language as if teaching a beginner; every breakdown point is a map of what you don't actually understand.
2. Check fit — if irreducibly formal, redirect; if you need speed, skip.
3. Elicit the specific concept. "I want to understand things better" is not workable; "I want to test whether I understand compounding interest" is.

[WAIT — do not advance until user responds]

4. One step at a time. Walk through each step with their actual concept; identify breakdown points together; locate source material for gaps.

[WAIT — do not advance until user responds]

5. Close by naming the specific gap most surprising — the thing the user thought they understood but the test revealed they did not.

[WAIT — do not advance until user responds]

The Process

Four steps producing a Feynman Understanding Audit. Stop rule: complete when explanation is genuinely plain — not when jargon is replaced with different jargon. If you cannot simplify further without factual loss, name the irreducible core.

1. Choose the concept and write its name. One specific concept, not a topic. "Compounding interest" is a concept. "Finance" is not.
2. Produce a plain-language explanation. As if to a curious 12-year-old: no jargon without definition, no circular definitions, no hedges. Record verbatim — do not edit in real time.
3. Diagnose the gaps. Mark every: (a) undefined technical term; (b) circular definition; (c) "it's complicated" hedge; (d) prediction that doesn't match reality. For each gap: name the specific question you cannot answer. Return to primary sources.
4. Simplify and refine. Rewrite incorporating what you learned. Test each analogy: does it break down where the original concept breaks down? If not, replace it.

Output template

text

Feynman Understanding Audit: <concept>
Initial Explanation: <verbatim, unedited>
Gap Diagnosis: location | type (circular/jargon/unjustified/hedge) | specific question I cannot answer
Sources consulted per gap: gap → source → what it clarified
Refined Explanation: <revised>
Analogies: analogy | works when | breaks down when
Summary: genuine (can reproduce/predict/extend) | surface only | irreducible core

→ Method in Action: Feynman and the Challenger O-Ring Investigation (1986)

Feynman Audit Packs

Domain	Surface recognition	Genuine understanding
Tech/engineering	Correct acronym use without explaining what problem each solves	Can predict failure modes and tradeoffs
Finance/investing	Fluent "DCF," "beta," "convexity" without explaining why formulas break down	Can explain to a non-finance person; spots when standard formulas give wrong answers
Leadership	Fluent framework use without explaining what behavior change each produces	Describes a concrete situation where each predicts a specific outcome

Contribute a Feynman Audit Pack: one file cataloguing the top 5–10 surface-recognition patterns and what genuine understanding looks like.

Applying It Well

• The gap is the output — not the explanation. Treat each gap as a precise instruction for what to study.
• Do not edit the initial explanation in real time — editing papers over gaps. Write first; diagnose second.
• Circular definitions are the most common gap — circle every term appearing in its own definition.
• "Basically" and "essentially" are gap markers — mark every hedge; they signal recognition substituted for understanding.
• Return to primary sources for gap-filling — a secondary summary may contain the same gap.

→ Primary sources: references/sources.md

Common Rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

Fake move	Reality
[D] "I know what it means, I just can't explain it simply."	This is the definition of surface recognition. If you understand it, you can explain it simply.
[D] Replacing jargon with different jargon.	"Capital allocation efficiency" for "return on investment" is not simplification. Test: can someone with no domain background follow it?
[D] Producing a correct-sounding analogy that predicts nothing.	An explanation producing no testable predictions has not conveyed genuine understanding.
[D] Treating it as a communication exercise.	The goal is to find where you cannot explain — not to produce a good explanation.
[D] Stopping when the explanation "sounds good."	A fluent jargon-reduced explanation ≠ genuine plain-language explanation. Test: does it predict outcomes and failure modes?
[D] Filling gaps with a secondary summary that has the same gap.	If you still cannot explain Y after reading "X works by doing Y," the gap is still open. Chase to a primary source.
[D] Accepting "it's complicated" as a valid stopping point.	It is never a conclusion — it is the beginning of gap diagnosis.
[D] Using the technique on too large a topic.	Identify the smallest falsifiable unit: a mechanism, a principle, a formula's derivation.
→ Add [O] entries here after each real use — paste the actual failure pattern	What went wrong and why

Red Flags

• "Plain language" explanation contains undefined technical terms
• No gaps identified — concept is trivial or diagnosis step was skipped
• Analogies not tested against failure conditions
• Gaps filled by secondary summary that "confirmed" original explanation
• "Basically," "essentially," or "kind of like" in refined explanation without unpacking
• Explanation cannot predict failure modes or boundary conditions

Verification

• Single specific concept chosen and named (not a general topic)
• Initial explanation produced verbatim, without real-time editing
• Each gap categorized: circular / jargon / unjustified / hedge
• For each gap: specific question that cannot be answered was named
• Gaps filled from primary sources, not secondary summaries
• Refined explanation tested: can someone with no domain background follow it?
• Analogies have explicit stated breakdown conditions

---

Part of deciqAI Knowledge Skills — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.