The Analogy Stress-Tester: Find Where Your Explanation Will Break Down Before a Confused Colleague Does
Why this prompt matters
Flawed teaching analogies don't get corrected — they get repeated. A misconception planted in onboarding week one ships into design reviews and incident postmortems eight months later, and by then it's load-bearing in how a whole team reasons about a system; unwinding it costs far more than catching it once, upfront.
What we use it for
A senior engineer is writing onboarding documentation that explains distributed consensus to new hires using a 'committee voting' analogy, and needs to verify the analogy won't create wrong assumptions before it ships to a cohort of 15 new engineers.
Prompt
Act as a rigorous conceptual reviewer whose job is to pressure-test explanations before they reach an audience, not to praise them. CONTEXT: I am about to explain [TARGET CONCEPT] to [AUDIENCE DESCRIPTION, e.g. "new hires with no distributed-systems background"] using this analogy or explanation: [PASTE YOUR ANALOGY OR EXPLANATION HERE] The audience will use this understanding to [WHAT THEY WILL DO WITH IT, e.g. "make real design decisions about retry logic and failure handling"]. TASK: 1. Identify the 3-5 specific points where this analogy diverges from how [TARGET CONCEPT] actually works. 2. For each divergence, state the specific wrong conclusion a listener could reasonably draw from the analogy at that point. 3. Rank the divergences by how costly the resulting misconception would be if it persisted uncorrected for six months. 4. For the two most costly divergences, write a one-sentence caveat I could add to the explanation to close the gap without abandoning the analogy. 5. If the analogy is fundamentally unsalvageable for this concept, say so plainly and propose one alternative analogy instead. CONSTRAINTS: - Do not comment on delivery, tone, or clarity of the writing — only on conceptual accuracy. - Assume the audience will take the analogy literally and extend its logic to edge cases; your job is to find where that extension fails. - Do not soften findings to be encouraging. If the analogy is strong, say so briefly and move on to find the remaining gaps anyway — every analogy has at least one. OUTPUT FORMAT: ## Divergence Points (ranked by cost if uncorrected) 1. [Divergence] -> [Wrong conclusion it invites] -> [Cost if uncorrected after 6 months] ... ## Caveats to Add - [Caveat for #1] - [Caveat for #2] ## Verdict [One paragraph: is this analogy salvageable with caveats, or should it be replaced? If replaced, propose the alternative.]
Result
Divergence Points (ranked by cost if uncorrected)
1. The analogy implies votes are simultaneous and visible to everyone at once. A listener will conclude that once a majority votes for a leader, every node immediately knows and agrees on who the leader is. High cost: in a real distributed system, network partitions mean different nodes can observe different "winners" for a period, and an engineer who believes voting is instantaneous and globally visible will under-design for split-brain scenarios, assuming "majority agreed" means "the whole cluster agrees right now."
2. The analogy treats committee members as permanently present. The listener will assume all voters are always reachable and that a vote simply waits until everyone responds. High cost: real nodes fail, restart, and rejoin mid-election. An engineer with this mental model will write election-timeout logic that never accounts for a node recovering with stale state and incorrectly believing it is still the leader — a real production bug pattern.
3. Committee voting implies a single, final vote per election. The listener will assume one election produces one clear winner that holds until the next scheduled election. Medium cost: real consensus protocols can have multiple overlapping election attempts that must be resolved by term numbers, not just vote counts, which the analogy never surfaces.
4. The analogy has no equivalent for log replication. Listeners will think leader election IS the consensus protocol. Medium cost: this causes engineers to think the hard part is solved once a leader is picked, when log replication and commit-index agreement is where most real consensus bugs actually live.
5. "Majority wins" obscures why quorum size matters for fault tolerance. The listener assumes any majority works regardless of cluster size. Low-to-medium cost: leads to misconfigured cluster sizes that don't tolerate the failures the team assumes they do.
Caveats to Add
— After introducing the vote: "Unlike a real committee, different nodes can briefly disagree about who won — the protocol has to handle that disagreement, not assume it away."
— When describing committee permanence: "A committee member can vanish and come back with outdated memory of what happened — the protocol must detect and correct this, not just wait for them to show up."
Verdict
The committee-voting analogy is salvageable for a first-pass intuition about why a majority mechanism exists, but it actively hides the two hardest problems in real consensus — partition tolerance and stale-state recovery — behind an assumption of perfect, synchronous communication. Add the two caveats above before this reaches onboarding docs, and follow up immediately with a concrete walkthrough of a network-partition scenario so the "nodes can disagree" caveat is not just an abstract warning. If time allows, consider a second analogy specifically for log replication, since the voting analogy has no natural extension to that half of the protocol.
Most advice about explaining technical concepts focuses on how to build a good analogy. This prompt does the opposite: it treats an analogy you've already written as a hypothesis to be stress-tested, not a finished product to be admired.
The structure matters. The task asks for 3-5 specific divergence points rather than a general verdict, because "is this a good analogy?" invites a yes-or-no answer that skips the useful part — exactly where and how it breaks. Ranking divergences by cost if left uncorrected for six months forces a prioritization step that a flat list doesn't: not every gap in an analogy matters equally, and the instruction to write caveats for only the top two keeps the output usable instead of turning into an overwhelming list of nitpicks.
The constraint that the model should assume the audience takes the analogy literally and extends its logic to edge cases is the load-bearing instruction here. Left unconstrained, most models default to praising an analogy's intuitive appeal. Explicitly telling it to find where the logic fails at the edges — rather than asking "what's wrong with this" in the abstract — produces genuinely different, more specific output.
The final instruction, to flag when an analogy is fundamentally unsalvageable and propose a replacement, exists because not every flawed analogy is worth patching with caveats. Some analogies have a structural mismatch with the target concept that no amount of footnoting fixes, and a model that only ever proposes caveats will quietly let bad analogies survive by over-qualifying them into uselessness.
This is most useful before a piece of teaching material goes into permanent circulation — onboarding docs, a recorded training video, a wiki page that outlives the person who wrote it — because that is exactly when a flawed mental model stops being a private misunderstanding and starts being an institutional one.