A problem that resists its own field's first principles has often been solved elsewhere, years ago, under a different name. Strip the jargon until the structure shows, find the isomorphic problems distant fields have already met, and transfer the mechanisms that solved them — only the parts that survive the move.
Write in the language the user writes in.
1. Strip the jargon
If the argument is missing or lacks the specific sticking point, ask one question for the missing piece and stop.
Restate the problem as one a person in any field could face — nouns replaced by roles (a scarce resource, a feedback loop, a trust gap, a queue). Then find three things:
- Underlying structure — the shape of the problem once the roles are named.
- Core tension — the two things that cannot both be had, stated as X pulls against Y because Z. The sticking point is a symptom of it.
- Why ordinary solutions fail — the fixes the user's field reaches for, and the specific reason each one breaks against that structure.
Synonyms are not abstraction: a restatement that keeps the field's nouns turns step 2 into a search for neighbours. Test it: a nurse, a farmer and a general should each be able to say "I have had that one." If a solution the user's field already uses would resolve the tension as stated, the tension is not yet the core one.
Done when the restatement contains no term from the user's field, and names the underlying structure, the core tension as two things pulling against each other, and one specific reason each ordinary solution fails.
2. Find isomorphic problems
Search historical cases and at least three fields for problems with the same underlying structure. Choose fields distant from each other and from the user's — distance measured by how little the practitioners would recognise each other's vocabulary. Historical cases come in addition to the three fields, and each carries a documented outcome.
Match on structure: a case that shares the user's nouns but faces a different tension is decoration; a case with alien nouns that faces the same tension, and whose ordinary solutions failed for the same reason, is isomorphic.
Where memory of a case is thin, WebSearch it; replace any case you cannot pin to a real field, a time and an outcome.
Done when there are historical cases, each with a documented outcome, and at least three fields, each distant from every other and from the user's, and every case passes the same-tension, same-failure test.
3. Take each case apart
For each case, in this order:
- What problem that field faced.
- The mechanism it used.
- Where it is similar to the user's problem.
- Which parts transfer.
- Under what conditions it fails.
The mechanism is the causal move, not the policy's name: "triage" is a name; "sort by marginal benefit of intervention rather than by severity" is the mechanism. Transfer names parts: the parts that ride on the shared structure move, the parts that ride on the field's own conditions stay behind. Failure conditions are the ones under which the mechanism stops working or backfires, written so the user can check their own situation against them.
Done when every case carries all five items, each mechanism reads as a causal move, each transfer names parts, and each failure condition is checkable against the user's situation.
4. Select and translate three mechanisms
Choose the three mechanisms most worth borrowing. Rank by how directly each attacks the core tension and how much of it transfers; a clever mechanism that touches a symptom loses to a plain one that hits the tension.
Translate each into a solution fitted to the user's situation — back into their vocabulary, inside their constraints, starting from their current approach. Name what changes, what it costs, and the failure condition from step 3 restated as the sign to watch for. "Do what that field did" is a pointer, not a translation; the translation is something the user could start.
Done when three mechanisms are each translated into the user's own terms, and each names the change, its cost, and its failure sign.
5. Recommend the first experiment, then deliver
From the three solutions, design the minimum experiment most worth running first. Low-cost: cheap enough, in money and effort, to run without asking anyone's approval. Reversible: undone without residue if it fails. Prefer the experiment that tests the core tension fastest over the mechanism that promises most. State the result that confirms the mechanism transfers and the result that kills it.
Deliver, in this order:
- Abstracted problem — jargon-free: the underlying structure, the core tension, and why ordinary solutions fail.
- Cases — the historical cases and at least three distant fields, each with its five items in order.
- Three mechanisms — each named as a causal move and translated into the user's situation, with its change, cost and failure sign.
- First experiment — the minimum experiment: low-cost and reversible, with its confirming and killing results and how to undo it.
Done when the experiment names its cost, its reversal, and its confirming and killing results, and every deliverable above is present in order.