The Feynman Check
Can you explain it simply? Where do you hesitate? Which term are you hiding behind? The hesitation is not a failure of nerve — it is the most precise locator of a gap in understanding there is, and the term you reach for is the gap's name.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
You believe you understand something and you want to find the exact place where you do not. How do you use a simple explanation as an instrument, and what do you do with the place it points at?
You are explaining the store's inventory to a new teammate. "When two customers buy the last unit at the same time, the database handles it — it uses a transaction." They ask what the transaction actually does that prevents overselling, and you hear yourself say "it locks the row, basically," and you are not sure that is what happens, or what "basically" is covering.
Use the right words and move on. "Transaction", "lock", "isolation" — the terms are correct, the teammate nods, and a more detailed answer would take you both into the weeds. Fluency with the vocabulary is what understanding sounds like.
The vocabulary is doing the work that the model should do. "It uses a transaction" is true and explains nothing, because a transaction without a conditional check or a lock oversells just as well as no transaction — and you would not have been able to say that, because "transaction" was where the explanation stopped.
- The vocabulary is doing the work that the model should do. "It uses a transaction" is true and explains nothing, because a transaction without a conditional check or a lock oversells just as well as no transaction — and you would not have been able to say that, because "transaction" was where the explanation stopped.
- The nod is not a check. The teammate accepted the term; neither of you learned whether the store actually prevents overselling, and the store is in production.
- The hesitation — "basically" — was the instrument reading, and the reflex talked over it. The one moment that pointed at the gap was treated as an awkwardness to be smoothed rather than a location to be marked.
- The gap survives, named by a term you now use with confidence. Confident use of a term you cannot unpack is the most durable form of not knowing, because nothing in your own speech will ever flag it again.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Explain it to someone who does not have the vocabulary, or to yourself as if they were there, and listen for two things: hesitation, and the moment you reach for a term. The hesitation says where the model runs out; the term says what you are using to cover the place where it ran out (Explain It Back).
- When you catch a term, unpack it one level: replace it with what it does, here, in this system. "It uses a transaction" becomes "the stock check and the decrement happen together, and — " and if the sentence cannot be finished, the gap is located precisely: you do not know what makes them happen together safely under concurrency, which is the actual question (Going One Layer Deeper).
- Treat the located gap as a specific unknown with an experiment, not as a reading assignment. "Does a transaction without a conditional update oversell?" is answerable with one table, one row and two concurrent requests, this afternoon; "learn about transactions" is a week and a feeling (Unknown, Question, Experiment).
- Distinguish a term you are hiding behind from a term you are legitimately abbreviating with. An expert says "it uses a conditional decrement inside a transaction" as shorthand for a mechanism they could unpack on request; the check is whether you can unpack it, not whether you used the word. Ask yourself to, once, and the answer tells you which kind of use it was.
The explanation, taken apart
The decomposition is the inventory explanation broken into the claims it makes, with each leaf carrying the observation that would show it is true. The leaf that was hiding behind "transaction" is the one whose observation had never been made; the check found it because the sentence could not be finished, and the tree records what finishing it required.
- └Both requests read the current stock— the check needs a valuetestable Two concurrent requests both log the stock they read; both see one.
- ├The check and the decrement cannot be interleaved by the other request— this is what "transaction" was covering
- └A transaction alonetestable Read → check → decrement inside a transaction, two concurrent requests: stock goes to minus one. The claim is false as stated.
- └A conditional decrementtestable Decrement where stock is at least the quantity, in one statement: the second request affects zero rows. The claim is true with this mechanism.
- └The losing request is told why— the customer must see somethingtestable Zero rows affected produces a "sold out" response, not a success and not a silent failure.
- └The winning request's payment is not taken if stock was lost later— stock and payment must not disagreetestable A checkout whose decrement failed never reaches the charge; verified by log in test mode.
The middle branch is where the hesitation was. The tree does not resolve it by reading; it resolves it by two experiments, and the second is the explanation the teammate should have been given.
From the hesitation to the experiment
The moment of hesitation produces a question, and the question is usually vague on its first appearance. The ladder sharpens it to the form with an experiment attached; the sharpening is what turns the check from a diagnosis into a plan.
why The best form names the setup, the two mechanisms to compare and the observation on each side, so it can be run in an afternoon and its answer is the explanation. The vague form sends you to a chapter on isolation levels; the better form has an experiment but only tests the mechanism you already doubted, not the one that replaces it.
The terms, and what stood behind them
The board is the list the check produced across the three worked cases: each term as it was used, the question it was covering, and the experiment that opened it. The known column is what the explanations bottom out in now — observations rather than vocabulary.
- ✓Overselling is prevented by a conditional decrement in one statement, not by a transaction alone — observed with two concurrent requests.
- ✓The losing request affects zero rows and is told "sold out" before any charge is attempted.
- ~The database executes a single conditional update atomically with respect to other updates on the same row — taken from its documentation, not yet observed under load.
? "The handler is idempotent."
becomes Idempotent with respect to what identity — the provider's event id, or the order reference — and what does the handler do when the two disagree?
experiment Send the same webhook twice, then a different event id with the same reference; log what each does; choose the identity and write why.
? "It uses retrieval-augmented generation."
becomes By what measure are passages judged relevant, and how often does the retrieved set contain the passage a person would have chosen?
experiment Ask twenty questions with known source passages; print what was retrieved; count the hits before touching the model.
? "The database handles concurrency."
becomes For the cart's add-twice case — not the stock case — can two concurrent adds to the same cart produce a wrong quantity, and does the store care?
experiment Two concurrent adds against one cart row; read the quantity; decide with the invariant written first.
Each term was fluent and each was covering a design decision. The check did not make the terms wrong; it made them openable, and the questions behind them are now the next afternoon's work.
How to do it
Most important first.
- Explain the mechanism out loud or in writing to an imagined non-expert, and mark every hesitation and every technical term as you go. Do not smooth; mark.
- For each term, write one sentence saying what it does here without using the term. A term that cannot be replaced is the one you are hiding behind.
- Turn the first unreplaceable term into a question with an experiment. Run the experiment before reading about the term; reading afterwards is confirmation, and it sticks.
- Re-explain after the experiment and see whether the hesitation moved. It usually moves one term deeper, and that is progress; the check is repeated until the explanation bottoms out in things you have observed.
- Keep the list of terms you could not unpack; it is the most honest syllabus you will ever have (The Engineering Notebook).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Inventory, checked. "When two customers buy the last unit, the database — " hesitation — "uses a transaction to — " term — "make sure only one succeeds." Unpack "transaction": "the check and the decrement happen together." Unpack "together": hesitation. The gap is located: what makes a check and a decrement safe against another request doing the same thing between them? The term "transaction" was covering exactly that.
- The experiment. One row, stock one, two concurrent requests, each doing read → check → decrement inside a transaction. Observed: both read one, both decrement, stock is now minus one. A transaction alone did not prevent it. Then a conditional decrement — decrement where stock is at least the quantity — and the second request affects zero rows and is rejected. Now the explanation is: "the decrement only happens if the stock is still there, in the same statement, so there is no gap for the other request to slip into." No term in it that cannot be unpacked; the hesitation is gone (Invariants Under Concurrency).
- Idempotency, checked. "The webhook handler is idempotent." Unpack: "if the same webhook arrives twice, the second does nothing." Unpack "the same": hesitation — the same by what? The provider's event id? The order reference? That question is the design decision the handler embodies, and the term was covering it. Experiment: send the same test webhook twice and once with the same order reference but a different event id; observe what the handler does with each.
- The AI assistant over company documentation, checked. "It uses retrieval-augmented generation." Unpack: "it finds relevant passages and puts them in front of the model." Unpack "relevant": hesitation — relevant by what measure? The gap is the whole retrieval design, and one term was standing in for it. The experiment: ask a question, print the passages retrieved, and judge whether a person would have chosen them.
How you know it worked
What now exists that did not before, and what question you can now ask.
- An explanation exists, in plain words, that bottoms out in mechanisms you have observed rather than in terms.
- A list of terms you could not unpack exists, each with a question and an experiment, and it is shorter than it was.
- The hesitation, when it comes, is marked and welcomed rather than talked over.
- A term you use as shorthand can be unpacked on request, and you have checked at least once that it can.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?Can I explain this without the vocabulary, and where exactly do I hesitate?
- ?Which term am I reaching for at the hesitation, and what does it do here, in this system, if I am not allowed to use it?
- ?What is the one experiment that would let me finish the sentence?
- ?Which of the terms I use fluently could I unpack on request — and have I ever tried?
What can go wrong
- Unpacking without end. "Conditional decrement" → "the database compares and writes atomically" → "the storage engine takes a latch on the page" → the SSD. Every explanation bottoms out somewhere; the check stops at the level where the store's invariant is guaranteed, and going further is a different lesson (Abstraction Levels).
- The check as performance. Explaining simply to impress rather than to locate, which means smoothing the hesitation — the one thing the check is for.
- Terms banned rather than unpacked. A learner who refuses to say "transaction" has not understood it either; the goal is a term you can open, not a vocabulary you avoid.
- The located gap sent to reading instead of experiment. "I hesitated at transactions" becomes a chapter, and the chapter is about isolation levels in general and not about whether this store oversells, and the hesitation is still there afterwards.
- Explaining without vocabulary is slower and, to an expert listener, tedious; the check is for finding gaps, not for communicating with peers, and using it in the wrong room costs credibility.
- The hesitation is uncomfortable in front of a teammate, and the reflex to smooth it is social, not intellectual; doing the check honestly in company requires a room where hesitation is safe.
- Every term unpacked opens another; the list is never empty, and deciding where to stop is a judgment the check does not make for you.
- "Simple explanation means dumbed down." It means each term replaced by what it does here. A simple explanation of the conditional decrement is more precise than "it uses a transaction", not less.
- "If I can use the term correctly, I understand it." Correct use is what the check is designed to see through. The teammate's nod proved the term was used correctly; the experiment proved the mechanism was not understood.
- "The hesitation means I should not have been explaining." The hesitation is the check working. An explanation with no hesitation either bottomed out in observation or was never honest.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALHesitation and the reached-for term locate gaps in any domain — a protocol, a proof, a policy; what changes is what the term is covering and how far down the unpacking has to go before it meets something observed.
- TEAM-SPECIFICAlone, the check is a notebook exercise and the only honesty required is your own. Explaining to a teammate is a better instrument — the hesitation is louder — but only in a team where hesitating is safe; where it is not, the reflex to smooth wins and the check is better done in private first.
- ILLUSTRATIVEThe new teammate, the "basically", the two-request experiment and the retrieval example are invented to show the check locating a gap; no real system or team is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's /manifesto/review turns this check on a generated answer: which term in the answer can you not unpack, and what experiment would open it?
- — /manifesto/without-ai lists explaining simply as one of its practices; this lesson is the instrument version of it.