What actually matters is far less intuitive, and it changes how we should think about LLMs as instruments for creativity.

The Broken Promise of the Creative Prompt

Ask any major LLM for novel solutions to a real problem and you usually get back a polished recombination of known best practices.

Take this question: How can we better prevent technical debt in large enterprise IT projects with fixed dates and budgets?

You’ll typically receive: short Agile sprints, 15-25% refactoring buffers, SonarQube, “stop the line” culture, and KPIs in vendor contracts. Useful and professional, but entirely predictable.

If you’re looking for established best practices, this is exactly what you want. The model is doing what it was trained to do, interpolating the most statistically probable patterns in its training data, and for consolidating known solutions that is a strength.

But if you’re looking for a genuinely new idea, something no one has tried, then that same interpolation is the obstacle. The model is fine; we’re asking it to perform the wrong operation.

Directed Metaphorical Association

Years ago, while researching creative systems, I started experimenting with a different approach: directed metaphorical association. Instead of asking for solutions directly, you identify the strong semantic concepts in a problem, pull rich metaphors from distant domains, transfer properties across the gap, and let the human judge what emerges.

The logic is simple. If you ask an LLM to solve a technical debt problem, it searches its training data for content about technical debt. You get back what the industry already knows. But if you ask it to find structural parallels between technical debt and, say, scuba diving, the model is forced to traverse a completely different region of its knowledge. The connections it finds can’t be recycled best practices, because no one has written about the intersection of nitrogen absorption and code quality.

At the time I developed this, it was all manual. Today, the attention mechanism in Transformer-based LLMs lets us scale this approach dramatically: the model can compute semantic relationships across domains far richer than anything I could code by hand.

But scaling it revealed something I didn’t expect. The results weren’t uniformly creative. Some metaphorical transfers landed immediately and felt actionable. Others were intellectually fascinating but resisted any practical application. At first I assumed this was noise, since some metaphors just work better than others. But the pattern was too consistent to be random, and it turned out to be more interesting than the ideas themselves.

Same Problem, Directed Metaphors

When I applied the method to the technical debt question, directing the LLM to generate metaphorical associations from distant domains rather than recombine known practices, four ideas emerged:

Directed fermentation. In cheesemaking, you don’t fight bacterial activity; you control which bacteria dominate. The distinction that matters is controlled versus uncontrolled, not clean versus dirty. A bad cheese isn’t a cheese with bacteria; it’s a cheese with the wrong bacteria.

Transfer: maintain a catalog of authorized shortcuts (a “starter culture”), each with its documented lifespan and self-replacement rule. Debt that follows the starter is tolerated. Debt outside it is rejected. You stop trying to eliminate debt and start trying to control which debt lives in your system.

Mandatory decompression. In scuba diving, nitrogen dissolves in the blood under pressure. That’s physics, not a negotiation. If the diver ascends too fast, the nitrogen forms bubbles. Since preventing nitrogen absorption is impossible under pressure, the solution is decompression stops, calculated mathematically and non-negotiable.

Transfer: accept that fixed deadlines and budgets will dissolve debt into the codebase. That’s a law of development under pressure, not a failure of discipline. Model debt accumulation as a calculable variable and insert mandatory decompression windows whose length is determined by the model, not by managerial goodwill. You don’t negotiate the laws of physics.

Programmed selective amnesia. The brain actively prunes weak synaptic connections during sleep. Forgetting is a survival mechanism, not a malfunction. Without this pruning, the brain saturates, loses its ability to discriminate, and starts treating noise as signal.

Transfer: at fixed intervals, delete entire modules and force them to be rewritten from their behavioral contract alone. This sounds radical, but the point is what the deletion reveals. Code that cannot be reconstructed from its spec exposes that the spec was insufficient: the real debt was in the specification all along, not in the code.

Unrehearsed ensemble. Jazz bands booked for festival slots with non-negotiable stage times cram complex new arrangements into minimal rehearsal hours. Every player memorizes the charts individually. But onstage, the improvisation falls apart into disjointed solos, because knowing the material individually is not the same as having internalized it as shared group intuition.

Transfer: a team where every developer knows the codebase individually can still produce incoherent architecture, because no one has built the shared intuition of how the system wants to evolve. The debt lies in the absence of collective internalization, which only emerges from working together on the same problems over time, rather than in any individual’s competence.

Something Is Off

Read those four ideas again. Two of them, fermentation and decompression, feel immediately actionable. You could present them to a project director tomorrow and have a productive conversation. They fit inside the existing mental model of how IT projects work; they just reframe a specific aspect of it.

The other two, selective amnesia and the unrehearsed ensemble, are more demanding. They don’t reframe an aspect of the existing model. They ask you to question what you consider the primary artifact (is it the code or the spec?), or what “team competence” even means (is it individual knowledge or collective intuition?). You can’t just “apply” them. You’d need to rethink something basic first.

This isn’t a question of quality. All four are intellectually rich. But they operate at different levels, and that difference is consistent and reproducible enough to be worth understanding.

The Red Herring: Semantic Distance

The obvious explanation would be that some metaphors are simply “too far” from the target domain. That’s the classical thesis from Mednick (1962): close associations are banal, distant associations are incomprehensible, and creativity sits in an optimal zone in between. It’s an elegant idea, and it has dominated the creativity literature for over sixty years.

But it doesn’t explain what we’re seeing here. Fermentation comes from biology. Selective amnesia comes from neuroscience. Both are roughly equidistant from software engineering. Yet the first is immediately applicable and the second is not.

If distance were the relevant variable, ideas from similarly distant domains should behave similarly. They don’t, so something else is at work.

First Finding: Transfer Granularity

What separates the two groups is the size of what gets transferred, not distance, since both draw from domains equally far from software engineering.

Look at what each idea actually imports from its source domain:

Fermentation imports a single rule: “the relevant distinction is not presence versus absence, it’s controlled versus uncontrolled.” One causal relationship, stripped of all cheesemaking context. You can plug it directly into a conversation about technical debt without asking anyone to change how they think about software.

Decompression imports a single rule as well: “accumulation under pressure is a physical law, and the stops are calculable.” The diving context is gone. What remains is a structural insight that maps cleanly onto fixed-deadline projects.

Now look at what the unrehearsed ensemble imports. Instead of a single rule, it brings a system of relationships: the idea that individual competence does not produce collective competence, that shared intuition is a distinct artifact that only emerges from sustained joint practice, and that the absence of this artifact produces incoherence even when every individual performs well. To apply this to a software team, you need to accept all of these premises simultaneously. You’re not plugging in a rule; you’re redefining what “team competence” means (a separate thing that either exists or doesn’t, rather than the sum of individual skills).

Selective amnesia does the same thing. It doesn’t just say “delete code sometimes.” It requires you to reconceptualize what the primary artifacts are, to accept that code is expendable and specs are foundational, to rethink the relationship between implementation and contract. That’s a system of interlocking ideas, not a single transferable rule.

Semantic distance matters: it ensures the pieces are genuinely different from what the target domain already knows. But the variable that predicts whether a metaphorical idea will be immediately useful is the granularity of the transferred unit. Single causal rules are portable. Systems of relationships require a worldview shift.

Both can be valuable, but they serve different purposes, ask different things of the audience, and land on very different timescales.

Second Finding: Compression at the Right Level

If granularity is what matters, the practical question becomes: how do you control it? How do you reliably extract single causal rules from a rich source domain instead of accidentally importing entire systems?

The answer is compression.

When you extract a causal rule from a source domain, you’re performing lossy compression in the information-theoretic sense (keeping only the causal skeleton, discarding everything else). You take a rich domain, scuba diving with its physics, decompression tables, equipment protocols, certification culture, and accident case law, and you compress it down to a bare skeleton: “inevitable accumulation under pressure → calculated mandatory stops.” Everything else gets discarded. What remains is portable.

What I didn’t expect is that this compression doesn’t work as a smooth dial you can turn gradually. It has discrete levels, like quantization of a signal (steps, not a ramp). In practice, I consistently see three distinct levels:

The raw metaphor. “Technical debt is like cancer.” This is barely compressed at all. The metaphor arrives with its full baggage: diagnosis, staging, treatment, remission, relapse, death. You’re not importing a rule; you’re importing a scenario, and the scenario drags in properties that don’t map to the target domain at all. (Does technical debt metastasize? Does it have remission? The metaphor implies yes, but the reality is more complicated.)

The causal rule. “Damage at a threshold triggers an irreversible state transition.” Now the source domain’s vocabulary has disappeared entirely. You can’t tell whether this came from botany, metallurgy, or nuclear physics; it’s a pure structural relationship. It’s abstract enough to travel across any domain boundary, but concrete enough to generate specific ideas when you apply it to a new context.

The philosophical principle. “Systems under constraint reach equilibria.” This is over-compressed. It’s true of everything: thermodynamics, economics, psychology, traffic. Precisely because it applies everywhere, it generates nothing specific anywhere. It’s a tautology dressed as insight.

The intermediate level, the bare causal rule, is the only one that is simultaneously abstract enough to leave the source domain and concrete enough to land in the target domain and generate something actionable.

Too little compression, and you import baggage. Too much, and you import nothing.

Useful creativity, it turns out, is a compression problem, and the sweet spot is a discrete level rather than a point on a continuous dial.

What This Means

These two findings already change how you use an LLM for creative work.

If you want ideas that are immediately actionable, direct the model to extract single causal rules from distant domains, stripped of all source vocabulary. Force compression to the intermediate level. If you can still tell which domain a rule came from, it’s not compressed enough. If you can’t imagine applying it to anything specific, it’s compressed too far.

But when I started applying this systematically, I ran into something I didn’t expect. I had a catalog of beautifully compressed rules. Each one mapped onto the target problem with uncomfortable precision. And yet I still couldn’t turn any of them into a solution. Understanding how a problem works turned out to be a completely different operation from knowing what to do about it. That gap, and what fills it, is what Part II is about.

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.

The Limitation I Didn’t See

By the end of Part I, I could reliably extract clean, compressed causal rules from distant domains. Rules like “accumulation under pressure is physics, not a choice” or “the distinction that matters is controlled versus uncontrolled.” Each one a precise diagnosis of how a problem works.

But that’s exactly what they were: diagnoses, X-rays of the pathology rather than solutions.

I spent a while assuming the solution would naturally follow from understanding the cause. It doesn’t. Understanding that nitrogen dissolves in blood under pressure doesn’t tell you to invent decompression stops. The leap from “here’s how the problem works” to “here’s how to break the mechanism” requires a separate act, one that is creative in a way the diagnosis is not.

When I systematized the method by asking an LLM to extract compressed causal rules from many distant domains at once, I could see this limitation clearly. The results were clean and powerful:

“Functional-but-carrying agents propagate the problem because there is no incentive to detect them.” (from epidemiology)

“Repeated sub-critical stress accumulates invisibly until failure occurs without proportional warning.” (from metallurgy)

“Control by outcome alone makes it impossible to distinguish systemic success from accidental success.” (from fermentation science)

Each maps onto technical debt with uncomfortable precision. The epidemiological rule describes how “working” code that carries hidden debt propagates undetected. The metallurgical rule describes how small daily compromises accumulate into sudden, catastrophic failures. The fermentation rule describes how testing only the final product hides whether the process was sound. Yet for all their diagnostic value, not one of them tells you what to do.

The Missing Operation: Inversion

The creative act that turns a diagnosis into a solution is inversion: deliberately breaking the causal chain at a chosen point.

In its simplest form, a diagnosis says “A causes B, which causes C.” Inversion asks what happens if I prevent A from causing B, or if I let B happen but prevent it from causing C. Each break point produces a different family of solutions, often of completely different nature.

In practice this is less obvious than it sounds, because a single causal chain can be broken at multiple points, and the choice of where to break determines not just the solution but its entire character.

Take the epidemiological rule: “functional-but-carrying agents propagate the problem because there is no incentive to detect them.” There are three links in this chain, and each one is a potential target:

Break at link 1: make the carrying agents non-functional. In software terms, design code so that debt-carrying modules stop working after a defined period. The debt itself triggers a forced replacement. This is a radical, architectural solution that changes the infrastructure.

Break at link 2: create incentives to detect, even when everything works. In software terms, reward teams for discovering latent debt rather than for delivering features. Don’t wait for symptoms; actively hunt for carriers. This is an organizational, incentive-based solution that changes the reward structure.

Break at link 3: accept propagation, but make its pathways visible. In software terms, don’t try to prevent debt from spreading; instead, instrument the codebase so that every propagation path is traced in real time. When something breaks, you know exactly which “carrier” transmitted the problem. This is an observational solution that changes what you can see.

One diagnosis yields three completely different solutions. The choice of where to break the chain is itself a creative decision that depends on the context, the constraints, and the appetite for disruption.

This is the operation that was missing from my original method. Extraction gives you a diagnosis. Inversion gives you families of possible solutions. But I wasn’t done, because the most powerful ideas I encountered weren’t single inversions. They were combinations.

Fourth Finding: Novelty Is in the Composition

Here is the central reversal of everything I thought I knew about creativity.

The entire creativity literature since Mednick (1962) has focused on the transfer as the source of novelty, on the assumption that the more distant the connection between domains, the more creative the idea. My own earlier research operated on this assumption.

What experimentation with LLMs at scale revealed is that distance is only a necessary condition. It ensures that the pieces you extract are sufficiently different from one another. But the novelty, the actual Eureka, doesn’t reside in any single extraction or any single inversion. It resides in the composition: the moment you assemble inversions from multiple, unrelated domains into a recipe that is specific to the target problem. The individual pieces aren’t surprising; the assembly is what no one has seen before.

In my own work using structural analogy as a diagnostic tool for organizations, I observe exactly this. When I import rules from biology, law, and neuroeconomics to analyze an organizational dysfunction, no individual rule surprises the domain expert. A biologist knows the first. A lawyer knows the second. An economist knows the third. What produces genuine insight is the combination: the specific way these rules interact when applied simultaneously to a context none of them were designed for.

Let me make this concrete with the technical debt example. Take two inversions from different rules:

From the epidemiological rule, break at link 2: create an incentive to detect even when everything functions normally.

From the fermentation rule: the relevant distinction is not presence versus absence, it’s controlled versus uncontrolled.

Now assemble them. You get something that, as far as I can tell, doesn’t exist in the current IT literature: reproductibility as the metric of code health.

A module is healthy not because it works, nor because its tests pass, but because two independent developers, starting from the same specification, would produce structurally similar code. If they wouldn’t (if the result depends heavily on who wrote it), then the module is a functional-but-carrying agent. It works, but its construction process was uncontrolled. It passed the outcome test while failing the process test.

Think about what this does. You’re no longer looking for bugs or measuring test coverage. You’re measuring whether the process that produced the code was controlled or accidental. The fermentation frame redefines what you’re looking for. The epidemiological inversion tells you when to look: precisely when everything appears fine.

Neither inversion alone produces this idea. The fermentation rule alone gives you a philosophical reframe, interesting but abstract. The epidemiological inversion alone gives you a detection strategy, useful but directionless. The invention is the recipe: reproductibility as a metric, triggered by the absence of alarm signals, designed to catch uncontrolled process masquerading as healthy output. It emerged from the composition, not from either piece.

Fifth Finding: The Solution Exposes the Context

There’s one more thing I got wrong initially, and it matters.

My first instinct, after developing the model, was to add a filtering step: take the composed ideas and check which ones are compatible with the target context. “This wouldn’t work here because of regulatory constraint X; eliminate it.” “This contradicts our governance model; eliminate it.” Standard feasibility analysis.

That instinct is a trap. A sufficiently compelling solution doesn’t get filtered by the context. It exposes the context. When a good idea collides with an organizational, regulatory, or cultural constraint, there are two readings: either the idea is unrealistic, or the constraint itself deserves to be questioned.

The most transformative Eureka is not “this solution works in my world” but “this solution is so compelling that I’m willing to change my world to make it work.” The friction between the idea and the context is a diagnostic of which constraints are actually serving you and which ones have outlived their purpose, not a bug in the creative process.

This has happened before at industry scale. Agile was not “applicable” in the world of waterfall. It didn’t fit the existing governance, contracts, or PMO structure. But it exposed that waterfall rested on a false assumption: that you can fully specify a system before building it. DevOps was not “applicable” in organizations where development and operations were separate silos with separate incentives. But it exposed that the separation itself was the root cause of deployment failures. In both cases, the idea didn’t adapt to the context. The context restructured itself around the idea, because the idea was compelling enough to justify the cost of change. Entire organizations rewrote their processes, their team structures, their governance models. They did so not because a consultant told them to, but because the solution showed the constraints to be obstacles rather than laws.

The idea didn’t adapt to the context. The context restructured itself around the idea.

The same mechanism operates at smaller scales. In my work at a major financial institution regulated by federal and provincial authorities, I’ve seen a creative solution to a development process problem run directly into a regulatory rule that everyone assumed was immutable. But the solution was transformative enough to create the will to engage the regulator in a conversation about whether that rule was still serving its original purpose. Instead of the constraint killing the idea, the idea questioned the constraint. And the list of constraints exposed became a deliverable as valuable as the solution itself.

The Complete Model

Creativity, then, is not a single operation. It is a sequence of three, which I’ll call the Extraction-Inversion-Composition framework (EIC):

Extraction. Compress distant domains into minimal causal rules at the right discrete level: abstract enough to be portable, concrete enough to be operational. This is the preparatory step. LLMs do it extraordinarily well.

Inversion. Identify where each causal chain can be broken. Each breakpoint opens a family of solutions of a different nature. The choice of breakpoint is context-dependent and already involves judgment, but an LLM can enumerate the options systematically.

Composition. Assemble inversions from different rules into a coherent recipe for the target domain. This is where genuine novelty emerges: in the combinatorics of the assembly, not in the individual pieces.

The framework rests on three claims, each of which challenges a different assumption in the existing creativity literature:

First, the causal rule (not the metaphor, the analogy, or the concept) is the correct unit of creative transfer. It is the only level of compression that is simultaneously portable and operational.

Second, inversion is the missing operation between diagnosis and solution. The creativity literature treats the transfer as the creative act, but the transfer only produces a diagnosis. Inversion produces families of solutions. Without it, you have insight without agency.

Third, novelty emerges from composition, not from transfer. The distance between domains ensures that the pieces are different. But the invention is in the assembly, in the specific combination of inversions that no one has tried before.

Each composed proposal is then judged on three levels of strength:

Logical strength: does the inversion actually break the causal chain? This is a structural coherence judgment. An LLM handles it well.

Transformative strength: is the solution compelling enough to justify questioning the constraints that stand in its way? An LLM can partially assess this; it can evaluate whether a proposal is radical and explain why.

Political strength: will the actual actors have the will and power to modify the exposed constraints? This is a situated judgment, anchored in knowledge of power dynamics, culture, and institutional history. Here, and only here, the human is irreplaceable.

What Comes Next

The EIC framework now feels complete on paper. But a model is only as good as its results in practice.

In Part III, I turn the framework into a concrete instrument (a carefully constrained prompt) and test it cold on three different LLMs with the same technical debt problem.

The results reveal something unexpected about the creative signatures of different models, about the limits of prompts as specifications, and about where human judgment remains irreplaceable.

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.

The Calibrated Prompt

Here is the prompt I now use. It implements the three EIC operations directly. Rather than a heuristic, the prompt is a constraint system designed to force traversal of distant conceptual spaces and prevent regression toward known solutions. Each constraint maps to a specific failure mode observed in testing:

 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

For the following problem:
[INSERT PROBLEM]

Step 1 — Extraction
Name 8-10 specific, concrete domains FAR from the problem domain.
Choose your own domains — do NOT reuse any domain mentioned
in this prompt. For each domain:
- Name the domain explicitly.
- Describe ONE specific phenomenon in 2-3 sentences.
- Extract the causal rule in the form
  [condition] → [mechanism] → [consequence].
- Compress until no domain-specific vocabulary remains.

TEST: if the compressed rule reads like systems theory, control
theory, or generic organizational advice, you haven't gone far
enough. Start over with a more concrete phenomenon.

Step 2 — Inversion
For each rule, identify 2-3 breakpoints in the causal chain.
For each breakpoint, describe a concrete intervention — not the
negation of the condition, but a structurally different mechanism
that disrupts the link. If your inversion is simply "do the
opposite," it's not an inversion — find a different angle.

Step 3 — Composition
Propose 3-5 recipes that combine inversions from DIFFERENT rules
(each recipe must use at least two). For each recipe:
- Name it.
- Explain how the inversions interact — what does their
  combination produce that neither produces alone?
- A strong composition does not just SOLVE the problem better.
  It REDEFINES what the problem is, what you measure, or what
  counts as success. If your recipe is a process improvement
  or an architecture, push further — what does it reveal about
  the problem itself that no one was seeing?
- Describe a concrete implementation scenario in 3-4 sentences.
- Assess its transformative strength.
- List the constraints it exposes.

Do not filter for current applicability. Maximize transformative
strength.

Every constraint in this prompt maps to a lesson from the theory. The self-test on extraction prevents over-compression to the philosophical-principle level. The “not the negation” rule on inversions prevents mechanical breakpoints. The redefinition instruction on compositions forces the model past the architecture level into genuine reconceptualization. Remove any of these constraints and the output quality degrades measurably.

What Happened When I Tested This

I gave this prompt cold to three different LLMs (ChatGPT, Grok, and Gemini), with no conversation, just the prompt and the technical debt problem. The results genuinely surprised me.

Both models produced legitimate creative output. The extraction worked: concrete domains (glassblowing, commercial beekeeping, bonsai cultivation, ice climbing, jazz band rehearsal), specific phenomena described in detail, compressed rules that were portable without reading like systems theory. The self-test constraint did its job: the models actually traversed distant domains instead of staying in abstract territory.

The inversions were also substantive. Rather than mechanical negations, they were structurally different interventions: “hot-swap modular subsystems as quick-replace cartridges,” “timber sold as regrowth futures contracts that pay bonuses only after next-cycle viability is certified,” “exhibition tree leasing model where operators display but do not own the final specimen.” These are genuinely inventive mechanisms.

The compositions reached the redefinition level. Both models produced statements that reconceptualize the problem rather than solving it incrementally. “Progress is not continuous delivery. Progress is the ability to survive interruption without degradation.” “There is no such thing as technical debt repayment. There is only continuous structural shaping.”

What interested me most, though, was that the two models produced qualitatively different results from the same prompt.

ChatGPT’s compositions were aphoristic and trenchant, tight redefinitions that read almost like proverbs. “Failure is not an event. Failure is a state the system is allowed to approach.” These are memorable and conceptually sharp.

Grok’s compositions were richer in texture and more operational. Where ChatGPT redefined in a sentence, Grok invented economic structures: “regrowth futures contracts,” “colony equity pools,” “maturity tokens that investors trade instead of bottled product.” Grok’s output was less tweetable but more implementable; you could see how to build each idea.

A third model, Gemini, pushed the extraction further still, into forensic taphonomy, dendrochronology, and ballistics, and produced what may be the most radical redefinition of all: the problem isn’t technical debt, it’s premature solidification. Debt is only debt if it’s locked into the final structure. Keep the system in a fluid state until the last possible moment, and the concept of debt dissolves entirely. Where ChatGPT redefined in aphorisms and Grok in economic structures, Gemini redefined through physical-state metaphors: a third creative signature from a third training lineage.

With the same theory, prompt, and problem, I got three different creative profiles. The difference lies not in the quality of the output but in its nature, and that nature is a direct reflection of each model’s training data and architecture. For any serious creative work, then, testing the same prompt across multiple models is essential rather than redundant, because each model will illuminate a different region of the solution space.

The Remaining Gap

The prompt produced results I’d call genuinely creative. But there’s a level it didn’t reach on its own.

Earlier, through sustained iterative conversation, I produced a concept (reproductibility as the metric of code health) that emerged from a specific collision between two specific rules at a specific moment of dialogue. I had noticed that causal rules were diagnostics, said so, and the model pivoted. That pivot, and the insight it produced, didn’t come from the prompt. It came from a human observing an intermediate result, naming what was wrong with it, and redirecting.

The prompt handles extraction and inversion reliably. It pushes composition to the redefinition level. But the highest-order insights, the ones that emerge from the friction between a human’s situated judgment and a model’s combinatorial power, still require iterative dialogue. The prompt is the instrument’s score; the conversation is the performance.

This has implications beyond creative brainstorming. The current industry push toward autonomous AI agents rests on the assumption that if the specification is good enough, the agent can execute independently. A spec, however detailed, is a frozen prompt. It captures intent at a point in time. What it cannot capture is the judgment that happens during execution: the moment when a human looks at an intermediate result and says “this is too abstract” or “you’re recombining known patterns” or “go further.” That judgment acts as a steering mechanism throughout, not as a quality check at the end.

This doesn’t mean autonomous agents are useless. They are interpolation engines, excellent for well-defined, bounded tasks where the acceptable output space is known in advance. But for any task that requires genuinely novel output (creative problem-solving, architectural invention, strategic design), the human in the loop is the creative engine rather than a safety net, and the LLM is the fuel.

Angine de Poitrine and the Universality Test

I developed the EIC framework through IT problems: technical debt, organizational architecture, QA strategy. But a theory of creativity that only works in engineering isn’t much of a theory. So I tested its limits against the most unlikely case I could find.

In April 2026, the masked math-rock duo Angine de Poitrine from Chicoutimi became the most viral act on Spotify worldwide. They play microtonal rock with polyrhythmic structures, wear papier-mâché masks, sing in an invented language, and describe themselves as a “Mantra-Rock Dada Pythagorean-Cubist Orchestra.” Their success is improbable by every industry metric, yet the model accounts for it.

Underneath their buzz lies a causal chain that no one has formalized. The music industry has been optimizing its output toward a statistical center for decades, through the formulas, timbres, and structures that maximize engagement. Generative AI accelerated this trend to a saturation point. As optimized content proliferates, the public loses its sense of human authenticity in what it hears. That erosion creates a need (not conscious, not articulated, but real) to reaffirm an identity distinct from the machine. And that need translates into a valorization of the improbable: the more something is manifestly non-optimizable, the more it functions as proof of humanity.

That’s a causal chain: [optimization saturation → authenticity erosion → need for human identity → valorization of the improbable]. You can extract it, compress it, invert it at different links.

But the composition thesis is what Angine de Poitrine validates most clearly. None of their ingredients is new. Math-rock has existed since the 1990s. Microtonal music since Charles Ives. Stage masks since the Residents. Dada aesthetics since 1916. Repetitive loops since minimalism. What is new is the recipe: the specific combination of these elements, in this order, with this attitude, at this precise cultural moment. No critic could have predicted that these ingredients, assembled this way, would produce a global phenomenon. The invention lies in the assembly.

They also validate the fifth finding most powerfully of all. The duo never filtered their art to fit the existing industry constraints. They didn’t ask whether instrumental microtonal rock sung in an invented language was “commercially viable.” By existing in authentically non-conforming fashion, they exposed that the industry had optimized humanity out of its own music. They succeeded because of their improbability, not despite it, and revealed the constraints of the system by refusing to submit to them.

Limitations

The EIC framework has boundaries I want to be explicit about.

The quality of extraction depends entirely on whether the model actually traverses distant domains or takes the path of least statistical resistance. The prompt constraints help, but they don’t guarantee it, and different models respond differently to the same constraints. There is no automatic way to verify that a compressed rule is genuinely novel rather than systems theory in disguise. That verification still requires human judgment.

Evaluating composition quality is harder still. I can recognize that “reproductibility as the metric of code health” is a redefinition rather than a process improvement. But I can’t formalize why I recognize it, which means I can’t automate the evaluation. Any benchmark built on this framework will require human evaluators, with all the subjectivity that implies.

The framework is strongest in domains with identifiable causal structures, such as engineering, organizational design, strategy, and medicine. I tested it against a cultural phenomenon (Angine de Poitrine) and the model held, but the causal structure there is in the system surrounding the artifact, not in the artifact itself. For domains where causality is less clear (pure art, fundamental research, philosophy), the framework may not apply, or may apply only partially.

Finally, the iterative conversation still produces results that the autonomous prompt does not. I’ve been honest about this throughout the article, but it bears repeating as a limitation: the EIC framework as a prompt is a useful instrument, but it is not a replacement for sustained human-LLM dialogue.

Then and Now

For a long time I thought creativity lived primarily in the metaphorical transfer, the initial connection between distant domains. LLMs gave me an experimental instrument I didn’t have before. By automating extraction at scale, they made visible what was hidden: transfer is preparatory. The real creative work happens in the composition.

One last thought. Beyond brainstorming, the prompt in this article can serve as a measurement instrument. Apply the same prompt to the same problem on different models and compare the results along three axes: depth of extraction, originality of inversions, and level of redefinition in compositions. My tests showed that different models produce qualitatively different creative profiles from identical inputs, and those differences are themselves interesting data. If researchers want to formalize a benchmark for computationally-assisted creativity, the EIC framework is designed to serve as a starting point.

The most powerful ideas are not the ones that adapt neatly to our current world, but the ones that make us willing to change it. Now I know what to look for.

But one question wouldn’t leave me alone. The EIC framework works forward, from problem to solution. But if causal rules are truly portable across domains, the framework should work in the other direction too. What happens when you start from a solution instead of a problem? That’s Part IV.

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.

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.

A Theory of Creativity First

Before building any system, I needed to understand what creativity actually is.

Here is the formulation I arrived at around 2005, working as a researcher in Québec City:

Humans cannot create something entirely new from nothing.

We can only perceive reality through our senses. You cannot imagine a color that does not exist. You cannot conceive a sound you have never heard. The entire domain available to human creativity is bounded by accumulated sensory experience.

Creative thinking is therefore combinatorial rather than generative ex nihilo. The only way to produce something genuinely new within a bounded experiential space is to discover a structural correspondence between two distant domains that are already known.

When that correspondence holds, it is a metaphor.

But novelty alone is insufficient. A creative idea must also be useful, and usefulness is not intrinsic to the idea itself. It is evaluated by a human observer with a specific problem and a specific set of objectives. The same association can be brilliant in one context and irrelevant in another.

This leads to a precise formulation:

A creative idea is an association between two distant known domains whose relevance is judged by a human evaluator as both novel and useful within a specific context.

Novelty is a function of semantic distance between domains.

Utility is a function of the match with the problem and with the evaluator’s own criteria.

From this theory, an architecture follows naturally.

The Architecture (2005–2010)

If creativity is the identification of structural correspondences across distant domains, then a system designed to assist creativity should not search for what is similar. It should search for what is structurally equivalent across distance.

Between 2005 and 2010, working at a private imaging company in Québec City, I designed and implemented such an architecture.

Each object in the system (initially images, but the framework was modality-independent) was described through three structured vectors:

• A composition vector capturing spatial organization, perspective, and luminosity
• An object-property vector encoding detected geometries, shapes, and physical attributes
• A semantic vector containing qualitative keyword descriptors

These vectors were computed automatically using classical computer vision techniques: color histograms, wavelet decompositions, geometric segmentation, texture analysis, spatial frequency distributions. Each image received a multidimensional signature, which we called a “genetic code,” stored in a database and queryable in real time across a collection of 100,000 images.

In today’s terminology: a hand-crafted feature-embedding pipeline feeding a structured vector database, with sub-second query response time. Built in 2008, before those words existed in this context.

But the architectural intent was quite different from similarity search.

The system did not ask: What is nearest?

It asked:

• Which objects share equivalent structural overlaps with a reference? (alternative objects: substitutable, not combinable)
• Which objects contribute complementary, non-overlapping components of a reference? (complementary objects: combinable to form a stronger metaphor)
• Which combinations increase analogical coherence rather than surface resemblance? (linked objects: internal reinforcement as a tiebreaker)

The metaphorical strength of a combination was computed as the aggregate overlap across structured dimensions. Combinations were ranked by analogical coverage, not by proximity.

A red apple and a white tablecloth, taken separately, are only partial metaphors for the Japanese flag. Combined, they cover it completely: one contributes the red circle, the other the white rectangle. Their combination scores higher not because they resemble the flag, but because together they account for its structure. That is analogy, not similarity.

Similar questions were being explored across content-based retrieval and computational creativity research during that period. The problem was recognized; what was missing were the representational tools to address it at scale.

Why This Distinction Still Matters

Modern embedding systems, including the best multimodal foundation models, are extraordinarily capable. They organize high-dimensional spaces where related concepts cluster together. Distance minimization in embedding space has proven to be a remarkably powerful paradigm.

But the analogical operation itself remains largely latent in these systems.

Current architectures optimize for distance, retrieve nearest neighbors, and interpolate within learned manifolds. They do not explicitly evaluate which pairs or sets of representations together form a structurally stronger mapping to a reference than any single element alone.

Foundation models can produce metaphor-like outputs through statistical association, sometimes impressively so. But the mechanism is emergent rather than structured, which means it cannot be controlled, composed, or inspected.

Making analogy a first-class, explicit, steerable operation in AI systems remains an open architectural problem.

What AI Still Needs

Revisiting this research today, three limitations of current AI systems stand out, each rooted in the same theory of creativity I was working from in 2005.

1. Implicit context inference

Human creativity does not operate in a vacuum. The relevance of any idea depends heavily on the context in which the human is operating: their constraints, objectives, mental state, environment. A skilled collaborator reads this context without being explicitly told.

Current AI systems depend almost entirely on what the user explicitly provides. They do not perceive the context in which the human evolves. For AI to become a genuine creative partner, it needs access to richer contextual signals, along with the capacity to infer meaning from them without requiring the human to articulate everything. That is a problem of situated cognition rather than retrieval.

2. Memory as a knowledge reservoir

In my theory of creativity, the quality of associative reasoning is directly proportional to the richness of available memory. More diverse experience means more potential connections across distant domains.

Current AI systems have impressive parametric knowledge, but their memory architecture is largely static between training runs. The strategic management of episodic, contextual, and long-term memory, treated as a dynamic, queryable reservoir that evolves with use, remains underdeveloped. Memory, in this view, is the substrate of association and not just storage.

3. Emotional memory

This is perhaps the most significant gap, and the one most likely to trigger an objection from researchers in reinforcement learning or affective computing.

The objection is predictable: AI systems do incorporate affective signals, through reward modeling, reinforcement learning from human feedback, and preference learning. This is true, and the work is serious.

But it addresses a different problem. These approaches treat affect as an external training signal: feedback injected during learning to shape behavior. Human emotional memory is structurally different. Rather than a signal applied to knowledge from the outside, it is woven into knowledge itself.

The neuroscientist Antonio Damasio demonstrated this precisely. Emotion is not separate from rational cognition; it is constitutive of it. Patients with damage to emotional memory centers do not become more rational. They lose the capacity to make decisions at all, because they can no longer assign differential weight to recalled experiences.

Every human memory carries affective encoding (fear, joy, discomfort, wonder) that influences which associations surface, which combinations feel meaningful, and which ideas resonate. This weighting is embedded in the retrieval structure itself rather than applied post-hoc.

Current AI systems process semantic relationships without this integrated affective architecture. The gap may therefore be architectural rather than merely incremental.

Building systems where affective structure is embedded in memory, instead of applied to it from outside, may be one of the most important open problems in AI research on creativity and reasoning.

Why I Am Writing This Now

The research described here was conducted between 2005 and 2010 and was not publicly discussed at the time due to contractual obligations.

Revisiting it now is less an exercise in retrospection than a recognition that the underlying questions remain open, and that the technological conditions to investigate them meaningfully finally exist.

I am not writing to claim priority. Parallel discovery is the norm in research, and I have no interest in relitigating timing. I am writing because the problem is still in front of us.

If you are working on reasoning architectures, compositional intelligence, contextual AI systems, or human–AI collaboration, I would like to talk.

The research described above is documented in an unpublished patent specification and a research poster produced in 2008.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era