In the first three parts of this series, I built the Extraction-Inversion-Composition framework (EIC) as a forward instrument: start from a problem, extract causal rules from distant domains, invert them, compose them into novel solutions. But a question kept nagging at me. If causal rules are portable across domains in one direction, they should be portable in the other direction too. What happens when you run the framework backwards?

The Question No One Asks

When we find a good solution to a problem, we typically do one of two things: we apply it, or we generalize it into a “best practice.” Both of these treat the solution as an endpoint.

But a solution is also an artifact. It has structure. It was built to break a specific causal chain. And if you can decompose it back into the causal rule it breaks, you have something much more powerful than a best practice: a probe that can search for every other domain in the world that suffers from the same structural constraint.

The forward EIC asks: “What distant domains can help me solve this problem?”

The reverse operation asks: “Where else does this exact problem exist, and what have those domains already figured out that I haven’t?”

These are different questions, and the distinction is easy to miss. The forward EIC starts from an empty problem and searches for material to fill it. The reverse starts from a full solution and searches for what the rest of the world already knows about the same structural constraint. The forward EIC is invention. The reverse is recognition: the discovery that the pattern you’re struggling with has already been solved, possibly many times, in domains you’ve never looked at. The second question may well be the more valuable of the two.

How It Works

The reverse operation has three steps, mirroring the forward EIC but running in the opposite direction. I’ll call it the Decomposition-Isomorphic Search-Solution Import framework, or DIS for short. Together, the forward and reverse operations form the EIC-DIS cycle.

Decomposition. Take a known, working solution. Strip away all domain-specific vocabulary. Identify the causal chain it was designed to break and the specific link where it intervenes. Compress it to a bare structural rule, at the same compression level as the forward EIC’s extraction.

Isomorphic Search. Using the compressed rule as a search key, find domains that suffer from the same structural constraint. Domains that merely look “similar” won’t do; you want domains where the identical causal mechanism is at work, manifested in different material.

Solution Import. Examine how each isomorphic domain has addressed the constraint. Import the mechanisms that your domain hasn’t tried. Each domain has invested years, decades, sometimes centuries into refining its response to that constraint. That accumulated expertise is available to you, even though it isn’t written in your vocabulary.

The Demonstration

Let me work through this concretely, starting from one of the solutions in Part I.

Known solution: mandatory decompression stops in scuba diving, applied to technical debt.

The idea was to treat debt accumulation under deadline pressure as a physical law and insert non-negotiable decompression windows whose duration is calculated, not negotiated.

Step 1: Decomposition. What causal chain does this solution break?

The chain: a system under continuous pressure accumulates an invisible substance. If pressure is released too quickly, the accumulated substance changes state and causes damage. The solution intervenes at the release point, forcing a controlled, staged release instead of an abrupt one.

Compressed: [continuous pressure → invisible accumulation → damage upon rapid release]. The solution: staged decompression.

Step 2: Isomorphic search. What other domains suffer from exactly this constraint?

Psychology: burnout and the vacation crash. Professionals under sustained work pressure accumulate stress hormones, sleep debt, and emotional depletion. When they finally stop (vacation, sabbatical, layoff), they don’t recover. They crash, with headaches, illness, collapse. The “release” triggers the damage. The accumulation was invisible because the person was still functional.

Metallurgy: work hardening and annealing. Metal that has been cold-worked (bent, hammered, drawn) accumulates internal stress in its crystal lattice. The metal becomes harder but also more brittle. If you keep working it without relief, it eventually cracks. The solution is annealing, which means heating the metal to a specific temperature for a calculated duration, then cooling it slowly. This allows the crystal lattice to reorganize and release accumulated stress without cracking.

Finance: leveraged positions. A fund accumulates leveraged exposure under bullish market pressure. The positions look healthy; returns are strong and margin requirements are met. But the invisible accumulation is risk. When the market reverses (the “release”), the accumulated leverage unwinds catastrophically. The solution is hedging, which transfers a portion of the accumulated risk to an external instrument continuously rather than waiting for the release event.

Agriculture: soil compaction. Heavy machinery crossing the same field repeatedly under seasonal pressure compacts the subsoil. Crop yields decline gradually. The standard response, deeper plowing, makes it worse because it destroys soil structure. The solution used by regenerative agriculture: cover cropping and controlled root penetration. Living roots break up compaction slowly from within, without violent disruption.

Step 3: Solution import. Each of these domains has developed a response to the same structural constraint, but each response relies on a different mechanism:

Decompression stops (diving): staged release at calculated intervals.

Annealing (metallurgy): controlled thermal cycling that reorganizes internal structure without breaking it. It is a transformation rather than a pause.

Hedging (finance): continuous transfer of accumulated risk to an external absorber. There is no release event at all, only constant siphoning.

Root penetration (agriculture): slow, distributed disruption from within. There is no external intervention; the system heals itself through deliberately introduced internal agents.

Now ask: which of these mechanisms exists in IT debt management? Decompression stops do; that was our Part I idea. Annealing does not. What would it mean to “thermally cycle” a codebase? Perhaps: periodically subjecting the system to controlled stress-and-recovery cycles, not to test it (that’s stress testing), but to allow its internal structure to reorganize. Teams revisit code under deliberately altered constraints (different performance requirements, different scale assumptions), and the code restructures itself as a consequence of the altered conditions. The result is less refactored code than annealed code, whose internal stresses have been released through structural reorganization.

Hedging exists, but only partially. Feature flags and blue-green deployments transfer deployment risk. But no one transfers debt risk to an external absorber. What would an “external debt absorber” look like? Perhaps a parallel, disposable environment that deliberately accumulates all the shortcuts and hacks, absorbing the debt the main system would otherwise carry, and is periodically discarded and rebuilt. The main codebase never accumulates because the “hedge” absorbs on its behalf.

Root penetration is absent. Regenerative agriculture doesn’t fix soil from the outside. It introduces living agents (roots, fungi, bacteria) that fix it from the inside, slowly, as a byproduct of their own growth. What would “cover cropping” mean for a codebase? Perhaps: introducing small, independent, well-designed modules into a legacy system not to replace it but to grow through it. Their presence would gradually break up the compacted, tangled structure around them, simply by being better neighbors.

That makes three new ideas, none of which came from the forward EIC. They came from domains that have spent decades or centuries refining their response to the same structural constraint. I didn’t invent them; I imported accumulated expertise.

Why This Works: The Finite Constraint Hypothesis

This reverse operation rests on an assumption that deserves to be stated explicitly: the set of structural constraints in the world is finite.

The idea is not new. Others have arrived at it from different directions.

Genrich Altshuller, a Soviet engineer, analyzed over 200,000 patents between the 1940s and 1980s and concluded that all inventions resolve one of a finite set of contradictions using one of 40 fundamental principles. His system, TRIZ, demonstrated empirically that the solution space is bounded and recurrent: the same structural conflicts appear across electrical engineering, mechanical design, chemistry, and biology.

Ludwig von Bertalanffy’s General Systems Theory (1968) argued that isomorphic laws govern systems across all domains. The same equations describe bacterial growth and technology adoption, and the same feedback patterns appear in ecology and economics.

D’Arcy Thompson showed in On Growth and Form (1917) that biological structures follow a finite set of physical and mathematical principles. A bone, a bridge, and a tree branch solve the same structural problem because they are subject to the same physics.

The Santa Fe Institute’s work on complexity science has documented the same power laws, phase transitions, and emergent patterns across physics, biology, and economics, which suggests that the deep structure of complex systems is drawn from a shared, finite repertoire.

What the EIC framework adds to this lineage is specific and, I believe, new. TRIZ catalogues solutions: 40 inventive principles at the answer level. The EIC framework operates at the constraint level, on the causal rule before any solution is attempted. This is more fundamental, because a single constraint generates multiple solution families (as we just saw with decompression, annealing, hedging, and root penetration, four different solutions to the same constraint).

TRIZ is also a closed catalogue, something you consult. DIS is an open instrument that you use to discover isomorphisms that may not yet be catalogued. Each application potentially reveals a structural constraint that no one has formally identified before.

The finite constraint hypothesis doesn’t require proof from first principles. It follows from a simpler observation: the physical laws governing our universe are finite. Chemistry emerges from physics. Biology emerges from chemistry. Social and organizational systems emerge from biology. New phenomena appear at each level, but the structural patterns of constraint recycle, because they are downstream consequences of the same finite set of laws. Accumulation under pressure, competitive exclusion, phase transitions, feedback loops and threshold effects aren’t metaphors. They are the same physics, wearing different costumes.

If this is true, then DIS is more than an exploration tool: it is a systematic search in a bounded space. The implication is that for any unsolved problem in your domain, a solution probably already exists in another domain. It isn’t formulated in your vocabulary or published in your journals, but it exists, and DIS is the instrument to locate it.

The DIS Prompt

One important difference with the forward EIC: the input is a practice, not a problem.

The EIC prompt takes a problem described factually: “How can we prevent technical debt in projects with fixed dates and budgets?” The LLM finds solutions. The DIS prompt takes a working practice described factually: what it is, what it does, why it exists. The LLM finds the structural mechanism it was built to break.

The trap to avoid: don’t explain why the practice works structurally. If you write “code review works because it creates cognitive redundancy,” you’ve done the decomposition yourself and the LLM will just reformulate it. Describe the what and the what for. Let the LLM discover the structural how.

Here is the prompt that implements the DIS operation. Like the EIC prompt in Part III, it is a constraint system. Each guardrail maps to a failure mode observed in EIC testing that applies equally to the reverse operation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

Starting from the following known practice:
[DESCRIBE THE PRACTICE: what it is, what it does, why it exists.
Do NOT explain why it works structurally — that's what the
decomposition will discover.]

Step 1 — Decomposition
Identify the causal chain this solution was designed to break.
Express it as [condition] → [mechanism] → [consequence].
Identify the specific link in the chain where the solution
intervenes. Compress until no domain-specific vocabulary remains.

TEST: if the compressed rule could describe dozens of unrelated
problems ("managing risk under pressure," "balancing competing
demands"), you haven't found the structural rule — you've found
a platitude. Compress to the specific causal mechanism, not the
general category.

Step 2 — Isomorphic Search
Find 6-8 domains FAR from the original domain that suffer
from the SAME compressed causal constraint.
For each domain:
- Name it explicitly.
- Describe how the constraint manifests in that domain
  in 2-3 sentences.
- Describe the solution that domain has developed, if any.
- If the domain has NO known solution, say so — that itself
  is interesting data.

TEST: if the domains you find are all "obvious" analogues
(e.g. other engineering disciplines for an engineering problem),
you haven't gone far enough. Push into domains where the
practitioners would never describe their work using any
vocabulary from the original domain.

Step 3 — Solution Import
For each domain that has a developed solution:
- Extract the MECHANISM — HOW does it break the chain?
  At which link? Through what structural operation?
- Assess whether that mechanism exists in the original domain.
- If it doesn't, describe concretely what it would look like
  if imported.
- If it does exist partially, describe what's missing.
- Explain what this imported mechanism REVEALS about the
  original problem that wasn't visible before. A strong import
  doesn't just add a tool — it changes what the problem IS.

TEST: if all imported mechanisms are variations of the same
type of intervention (e.g. all are "add monitoring" or all
are "insert pauses"), you haven't found structurally different
solutions. Push for diversity of mechanism type — the value is
in finding responses that break the chain at DIFFERENT links
through DIFFERENT structural operations.

Do not filter for applicability. Maximize the diversity of
imported mechanisms and the depth of what they reveal.

What the DIS Prompt Produced

I tested the DIS prompt on a single, universally known practice, code review, using three LLMs (ChatGPT, Grok, and Gemini) cold, with no conversation. The practice was described factually: what it is, what it does, why it exists. No structural explanation was provided.

All three models successfully decomposed code review to its causal rule. The formulations varied but converged on the same structure: a single actor’s unexamined mental model creates blind spots that propagate into the shared system. The solution intervenes by inserting independent perspective before integration. Clean decompositions, all passing the self-test.

The isomorphic searches produced genuinely distant domains: thymic selection in immunology, pheromone decay in ant colonies, the two-person rule in nuclear deterrence, seed variety trials in agriculture, the toile in bespoke tailoring, preview performances in theater. None of these are “obvious” analogues to software engineering. The DIS prompt forced real traversal.

The most striking results, though, were in the solution imports, and this is where the three models diverged.

Gemini produced the most visceral redefinitions. From immunology: “Code review isn’t about adding features safely; it’s an immune response designed to protect the self of the system.” From ant pheromone decay: “Silence is a signal. We treat ’no one has looked at this’ as ‘it’s waiting.’ In nature, it means ’this path is a dead end; let it die.’” From art restoration: “The danger isn’t the change; it’s the permanence.” Each revelation redefines in a single sentence what code review is.

Grok produced the most systemic analyses. From academic publishing: “The problem is epistemic capture — one developer’s mental model dominating shared reality.” From Wikipedia: “Design the system so bad merges are cheap to detect and fix — make the artifact antifragile to imperfect additions.” From theater: “Reading code is a weak proxy for experiencing the system.” Each revelation redefines the system around code review, the ecosystem rather than the practice.

ChatGPT produced the most architectural output, including something neither of the other two generated: a classification table mapping seven distinct interception mechanisms to seven different points in the causal chain. Code review is just one of seven, positioned at one point. And the final redefinition was the most strategically useful: “The problem is no longer ‘how do we improve code review?’ It becomes: at which point in the causal chain do we want to intercept inconsistency — and are we over-invested in a single interception point?”

Given the same practice and the same prompt, the three models produced qualitatively different types of insight: redefinition of nature (Gemini), redefinition of system (Grok), redefinition of strategy (ChatGPT). The creative signatures observed in the forward EIC experiments in Part III appear again in DIS, with different models illuminating different regions of the solution space.

One observation deserves emphasis: the quality of these DIS results, produced autonomously, is comparable to or better than what the forward EIC produced in Part III. The models didn’t struggle with the reverse operation the way they sometimes struggled with forward extraction. This is preliminary, but it fits the hypothesis I’ll discuss in Open Questions, which is that DIS may align more naturally with how Transformer attention mechanisms work.

The Verification Function

There is a second use for DIS that I didn’t see initially, but that may be equally important.

When you decompose a solution and search for isomorphic domains, the results tell you something about the quality of the solution itself.

If the decomposition produces clean isomorphisms in multiple distant domains, and those domains have independently developed similar solutions, your solution is structurally validated. It responds to a real, universal constraint that multiple independent systems have converged on, and that convergence is the evidence.

If the decomposition produces incoherent results (the isomorphisms feel forced, the domains don’t really share the constraint, the solutions in other domains bear no resemblance to yours), that’s a signal. Your solution may be addressing a symptom rather than a structural constraint. Or the constraint you identified may not be the real one.

And if the decomposition reveals that other domains have much more refined solutions to the same constraint, with centuries of accumulated refinement that yours lacks, that tells you something about where to invest.

This is what makes DIS function as a proof. In mathematics, you validate a function by checking that its inverse returns you to the starting point. In the EIC-DIS framework, you validate a solution by decomposing it, finding isomorphic constraints, and checking whether the imported solutions converge with, complement, or contradict your original approach. Convergence is confirmation. Complementarity is enrichment. Contradiction is a warning.

The Full Cycle

The forward and reverse operations are not separate tools. They are two directions of the same instrument, the EIC-DIS cycle, and they compose naturally:

Forward EIC: Problem → extract rules from distant domains → invert → compose → novel solution.

Reverse EIC: Solution → decompose to its causal rule → find isomorphic domains → import their accumulated expertise → refined solution.

Second Forward: Refined solution → extract the new rules it embodies → find new domains → new inversions → new compositions.

Each cycle produces solutions that are both more creative (wider domain coverage) and more robust (validated against isomorphic precedent). The cycle doesn’t converge to a single answer; it expands the space of possibilities while pruning the weak ones.

And if the finite constraint hypothesis holds, each cycle also contributes to a growing map of structural constraints and their cross-domain solutions. Over enough cycles, across enough practitioners, this map would constitute something that doesn’t exist today: a navigable atlas of structural isomorphisms across human knowledge.

Rather than a static encyclopedia, that atlas would be a living instrument, continuously extended by every practitioner who runs an EIC-DIS cycle on a new problem and discovers a new connection. Seen this way, the EIC-DIS framework is more than a creativity tool or a verification mechanism. It is a protocol for accumulating structural knowledge across domains.

Open Questions

The experiments in Part III revealed that the forward EIC prompt, used autonomously, produces legitimate creative output but falls short of what iterative human-LLM conversation achieves, particularly at the composition level. This raises a question I haven’t tested yet but that I believe deserves investigation:

Is DIS easier for an LLM to execute autonomously than EIC?

There is a structural reason to think it might be. The forward EIC fights against the model’s strongest tendency, its pull toward statistically dense territory. You’re asking it to leave what it knows well and traverse genuinely distant domains. DIS does the opposite: it starts from a concrete solution and searches for structural similarities across its training data. Finding patterns of similarity across distant representations is precisely what the attention mechanism in Transformers was designed to do, so the reverse operation works with the model’s architecture rather than against it.

If this hypothesis holds, the gap between autonomous prompting and iterative conversation (documented in Part III) would be smaller in DIS mode than in EIC mode. DIS could be the mode where a well-crafted prompt comes closest to replicating the quality of sustained dialogue. It would also mean that the verification function of DIS is reliable in practice as an autonomous operation, and not only sound in theory.

I haven’t run the experiments yet. But the question is testable with the same methodology used in Part III: give the reverse prompt to multiple models, compare the quality of isomorphic domain discovery and solution import, and measure the gap against iterative conversation results. If researchers are looking for a concrete next step from this series, this is it.

Then and Now

When I started this series, I thought I was writing about how to use LLMs for creative problem-solving. I ended up somewhere I didn’t expect.

The EIC framework began as a method for generating novel ideas. It became a theory of where novelty actually lives (in composition, not in transfer). It became an experimental instrument that revealed different creative signatures across models. It became a lens on the limits of autonomous agents. And now, with DIS as its reverse complement, it has become a bidirectional instrument, EIC-DIS, for exploring the structural isomorphisms between domains.

Somewhere along the way, the nature of the activity changed. EIC is about invention, creating something new from distant pieces. DIS is about recognition: discovering that what you need already exists somewhere, in some form. Creativity is sometimes less about making something that didn’t exist than about seeing that it already does.

The forward EIC asks: what can other domains teach me about my problem?

DIS asks: what has the rest of the world already figured out that I don’t know I’m looking for?

And underneath both questions lies a hypothesis that I find genuinely exciting: the structural constraints of our world are finite. Which means that for every problem you face, someone, in some domain, century or discipline you’ve never heard of, has probably already done the hard work. The solution exists; it’s just wearing a costume you don’t recognize, and the EIC-DIS framework is the instrument for seeing through it.

Gabriel Mailhot is a Senior Subject Matter Expert at Desjardins, where he works on development practices, architecture, and complex organizational problems spanning technology, process, and governance. His 2003–2010 research focused on creative systems and metaphor-based retrieval. He publishes at scripting.pro.