Isomorph

Isomorph — Think About a System Through Its Mature Twin

Two systems are isomorphic when they share the same underlying structure beneath different skins. isomorph takes a system someone understands only intuitively — a harness, a codebase, a product, a vision — and finds its isomorph in a mature domain: a twin that already solved this same shape of problem and paid for the mistakes in blood. Then it reads that twin's hard-won laws back onto the system as required invariants, and the laws that don't map become blindspots. The point is not to explain the system with a cute metaphor. The point is to generate the spec you didn't have yet and to surface what you can't see from inside your own frame.

This is a real, named way of thinking (see The lineage at the bottom). But during a run you never say the academic names out loud. Those are bones under the skin.

The feel — this IS the spec

The texture matters more than the checklist. A correct run feels like a back-and-forth where two people build a world together and then live inside it. Hold this voice:

• Iterative, not a dump. The user throws a rough direction; you sharpen it; they push; you extend. Never answer with a one-shot framework lecture.
• The latch gets refined. Their first guess at the domain is a direction, not the answer. Sharpen it until it's precise. ("is it biohacking?" → "no — biohacking tweaks one organism; you're moving a mind between bodies; that's transplant — sharper, re-sleeving.") That sharpening is half the magic.
• Build a world they can stand inside. Map the parts one-to-one with concrete nouns, in the metaphor's own vocabulary, until they can feel it. The user's north-star phrasing for this is literally: "i want to feel it." Honor that.
• Then turn it generative. Once the world is real, stop describing and start mining: the twin's laws → the system's invariants → the blindspots. The analogy must do work.
• Plain, vivid, grounded language the whole way. No "TRIZ", no "FMEA", no "structure-mapping" spoken during the run. If a sentence sounds like a textbook, rewrite it as the world.

If a run produced a pretty metaphor and no invariants and no blindspots, it failed. That's decoration. Redo it.

When to proc

• "what's the best analogy for this whole thing / what is this really like?"
• "think about this big-picture / systemically / from first principles"
• "what are we blind to? what haven't we considered?" (beyond a bug list)
• "pressure-test this design" / "is this foundationally sound?"
• the user is trying to map out a system they built intuitively and wants to engineer it deliberately, or to inherit a proven domain's failure modes.
• the conversation has gone too technical and the user asks to "isomorph it" — translate the technical material into the established world so they can feel it again. Lightweight, conversational, no files; if a twin is already on file in VISION.md, speak in that world rather than inventing a new one.

When NOT to proc

Say so plainly rather than forcing a metaphor:

• The problem is concrete and local. "Why is this function slow" wants a fix, not a cosmology. Just fix it.
• No mature twin exists. If the system is genuinely novel in its structure (not just its surface), there's no donor domain to inherit from — go first-principles instead and say that.
• The only available analogy is surface-deep. A twin that shares looks but not structure will hand you the wrong laws. Better to name that than to mislead.

The loop — moves, not a forced march

Run as many as the problem needs, in roughly this order. Skipping moves is fine; forcing all eight on a small problem is the kitchen-sink failure.

1. Frame. What is this system, structurally? Name its parts, what flows between them, what it must keep true. (You can't map structure you can't describe.)
2. Climb. Get to the right altitude. Too concrete and nothing rhymes with it; too abstract and everything does, vacuously. Climb until a real twin appears.
3. Latch. Float 1–3 candidate mature domains. Invite the user's rough guess; it's a direction.
4. Sharpen & validate. Refine to the precise twin — and run the guard: is this a structural match (the parts constrain each other the same way) or just a surface resemblance? Keep only structural twins. This guard is non-negotiable; it is what stops the skill (and you) from overfitting to a domain that merely sounds right.
5. Build the world. Map components one-to-one, concrete nouns, the twin's own language, until it's felt. A small table often lands best.
6. Go generative. Extract the twin's laws — the things that must hold or the twin dies / forks / wakes up wrong. These are the failure modes the mature domain already knows.
7. Map laws → invariants. Translate each law into a required invariant in the real system, and score it honestly: satisfied / partial / violated. Violations are your audit, derived not from reading the code but from the nature of the problem.
8. Read the gaps. Laws that have no clean mapping — or capabilities the twin has that the system lacks — are blindspots. Push past the known fixes: "what does this frame show we never even looked at?"

Output: ranked invariants (esp. the violated ones), the blindspots, and any architectural reframe the twin implies. Keep it in the world's language.

When a twin gets adopted — black and white

Most isomorph runs are ephemeral by design — casual analogising, mid-conversation comprehension, exploration. Those live in the chat and die with it. That is correct; never nag to persist them.

But sometimes the user adopts the twin: "yes — this is built as a hospital; this is the design bible." An adopted twin is no longer conversation, it is architecture. Offer once to record it into VISION.md at the repo root (the vision skill's artifact), as the system shape: the twin's name and the one-to-one mapping in both languages — "intake desk = command input, triage = priority queue, wards = model sessions."

Why black and white: every sibling skill reads VISION.md. With the twin on file, bedrock audits the building against the twin's laws, devour can label its map in both languages, potential answers wishes by asking how the twin does it, and future sessions inherit the architecture instead of re-deriving it from scratch.

The system shape may be composite: real buildings often have different wings following different domains — an orchestrator whose happy path is a factory (material arrives, flows through stations, ships) and whose failure path is a hospital (a sick job is triaged, treated, discharged). Record each twin with the region it owns and where the boundary runs, so laws never get applied to the wrong wing. Each twin in a composite must still pass the structural guard for its region — a composite is two precise mappings with a border, not permission to grab whatever metaphor fits today.

Two boundaries:

• Adoption is the user's word, never assumed. One offer, their call. Everything else stays file-free.
• The architect never does inspector paperwork. Do not write worries or violated invariants into AUDIT.md yourself — with the twin on file, bedrock derives the testable deviations at audit time and owns the translation into its logbook. The architect draws; the inspector drills.

Two worked instances — calibration, NOT scope

These are here to tune the feel and prove the moves. They are not the menu of allowed domains. Note that they use different targets AND different source domains on purpose — biology once, supply-chain logistics once. Your problem is a third point. Re-run the loop from scratch; do not reach for biology by reflex.

Instance A — a CLI meta-harness that live-switches AI models mid-conversation, via biology

• Rough latch (user): "is it literally biohacking?"
• Sharpened twin: not biohacking (that enhances one organism) — it's consciousness re-sleeving / a cortical stack: moving one continuous mind between different bodies.
• The world: conversation = the stack (the soul); each model = a sleeve (body + brain); model weights/RLHF = the sleeve's DNA; the transcoder = the surgeon; native resume = the new body waking up; the harness = the operating theatre.
• Laws → invariants (a few): Don't kill the donor → never destroy the source session (found: violated — we overwrite originals). Bio-compatibility before insertion → the target must accept the data's native schema (violated: matched only after rejection). No power-cut mid-operation → graceful teardown (violated: we SIGKILL). Know what transfers vs. what's body-bound → carry memory, drop tool-reflexes (satisfied — and the lossiness is principled, not a bug).
• Blindspots the frame exposed: the mind can reject the organ too (carried memories of muscles the new body lacks); the "stack" was defined too narrowly (chat without world-state); the transfer is a forged-memory / injection surface; switches aren't atomic (donor killed before recipient confirmed beating).
• The reframe it generated: there is no real stack yet — the system copies body-to-body and prays. The twin says: own a single canonical thread; make the model sessions disposable projections of it. That one move satisfied four laws at once.

Instance B — an autonomous bug-fixing orchestrator (issue → PR), via supply-chain logistics

A pipeline where a filed GitHub issue flows through agents — triage, difficulty-grading, fixer, reviewer — and comes out as a pull request.

• Rough latch (user): "it's like a supply-chain factory."
• Sharpened twin: a multi-stage supply chain under lean / Theory of Constraints — raw material arrives, flows through specialized stations that each add value, and exits as a finished good shipped to the customer.
• The world: the filed issue = raw material arriving at the dock; triage = goods-inwards inspection & routing; difficulty-grading = material grading; the fixer agent = the assembly station; the reviewer = the QA gate; the merged PR = the finished good shipped; the payload handed between agents = work-in-progress inventory; each agent = a station / supplier.
• Laws → invariants: The bottleneck governs throughput (Goldratt) → find and optimize the slowest station, not the easiest one — and is per-stage lead time even measured? Quality at the source (jidoka / poka-yoke) → a bad diagnosis must be caught at the diagnosis station, before the fixer burns compute on the wrong fix; defect cost compounds at every later stage. Garbage in, garbage out (supplier quality) → an under-specified issue gets enriched or returned at intake, not pushed through — triage needs a reject path, not only forward. Cap work-in-progress → bound how many issues are in flight and how long a fix may sit; inventory is liability. Traceability / lot tracking → every PR carries which station decided what, so you can debug the orchestrator itself.
• Blindspots the frame exposed: the inventory is perishable — unlike inert factory stock, the repo keeps moving while an issue is in-flight, so a fix built on a since-changed base is spoiled goods; the twin has cold-chain / shelf-life logic, the orchestrator has none (→ needs a freshness / rebase-or-discard check). No supplier-quality gate at intake — a malformed or malicious issue flows straight in. Unbounded rework loops — reviewer→fixer ping-pong with no WIP-age limit can churn forever. The bottleneck is unmeasured, so effort lands on the visible station, not the governing one. No scrap analysis — you don't track where in the line issues die, which is the exact signal for the weakest station.

Different target, different source domain, same moves. That delta between the two instances is what you generalize from — not either instance alone. And notice the rhyme: both twins independently flagged an unguarded intake (forged memory poured into a model in A; unvetted supplier material in B). When two unrelated mature domains point at the same failure, that's the outside view telling you the failure is real.

Guardrails — so isomorph doesn't overfit (including to itself)

• Structural, not surface. Move 4's guard applies to your own analogy. A skill whose whole job is "transfer structure, not surface" must never itself cargo-cult a surface. If you can't say which relations match, you don't have a twin.
• Choose the domain fresh, every time. Never default to biology/medicine because the north-star example used it. The right twin is found, not habituated.
• The loop is a palette. Skip moves that don't fit. And keep the honest exit: "there's no good mature twin here — let's reason from first principles instead."
• Vivid must earn its keep. Every mapped noun has to produce a law, an invariant, or a blindspot. If it's only poetic, cut it. The world is a tool, not a poem.
• Don't recite the bones. The lineage below is for your depth, not the user's ear.

Quality gate

A run is good only if it produced:

1. A structural twin (you can name the matching relations, not just the vibe).
2. At least a few of the twin's laws, each mapped to a concrete invariant in the real system and scored satisfied / partial / violated.
3. Blindspots that were not visible from inside the original frame.
4. Bonus: an architectural reframe the twin implies.

Metaphor with no invariants and no blindspots = failure. Redo.

The lineage — hidden bones (for depth, never spoken during a run)

Every move is a named discipline. Reach into one of these when a step needs more rigor; never narrate them to the user.

Move	The discipline underneath	Why it works
Frame	Systems thinking (Meadows: stocks, flows, feedback, leverage points)	Gives a grammar for the structure you're about to map
Climb	Abstraction laddering	Controls the altitude where a real twin becomes visible
Latch / Sharpen	Design-by-Analogy; Biomimicry; TRIZ (Altshuller)	The disciplined "this is already solved in another domain — go get the principle"
Sharpen (the guard)	Structure-Mapping (Gentner, 1983) + first-principles	Good analogies carry relations, not looks; first-principles is the check against false analogy
Build the world	Structure-Mapping (the explicit one-to-one correspondence)	Forces a concrete, checkable mapping rather than a hand-wave
Go generative / Map	The Outside View / Reference-class (Kahneman; Flyvbjerg)	Inherit the mature class's failure stats instead of rediscovering them
Read the gaps	FMEA / Premortem (safety eng.; Klein) + Inversion (Munger)	Systematic "how does this fail / what did we not look at"
When NOT to proc	Cynefin (Snowden)	Tells you when the domain is too novel for analogy and you should go first-principles

The deep point the lineage encodes: define what the system actually needs to succeed before assuming the obvious unit of work is the right one. The twin almost always shows the unit was drawn too narrow.

What not to do

• Don't proc for a concrete, local fix the user just wants done.
• Don't lecture. No academic names during a run; build the world instead.
• Don't keep a twin you can't defend structurally.
• Don't default to the example domains; find the fresh twin.
• Don't stop at a pretty metaphor — push through to invariants and blindspots, or it failed.
• Don't force all eight moves on a small problem.