Governing Metaphor

Dreamineering treats metaphor as architecture of understanding, not as decoration. A good metaphor is not a stylistic flourish — it is a transfer structure that gives people a new way to see and organise a domain so they can think and act differently.

Why This Is the Standard

Aristotle’s metaphor of metaphor (via Diegesis) is about conceptual transfer: something “foreign” from one domain is brought into another and gives the target a new role and a new way to be seen. That is the bar. A Dreamineering metaphor should not just sound intelligent; it should transfer a working structure from a source domain into a target domain so the reader can act, not only admire.

The Test

For every metaphor you use, ask:

#	Question	Pass condition
1	What is the source domain?	Named (e.g. control systems, vision, instruments).
2	What is the target domain?	Named (e.g. progress, money, product).
3	What structure is being transferred?	Orientation, iteration, precision, potential — something concrete.
4	What new role or behaviour does this create in the target?	The reader can do or see something they couldn’t before.
5	Does it help the reader act, or only admire?	If it only impresses, it’s ornamental. Cut or replace.

If a metaphor cannot pass this test, treat it as ornamental and remove it or make it operational.

Strong Examples (Dreamineering)

These pass the test:

Metaphor	Source domain	Target domain	Transfer
Picture of success	Vision / image	Planning, progress	Orientation, visibility, wayfinding, shared perception
Feedback loops shape destiny	Control systems / cybernetics	Life, org development	Iteration, correction, compounding, path dependence
Digital instrument	Tool / instrument performance	Website, product	Precision, responsiveness, intentional design, learned mastery
Money is tokenised time and energy in stored opportunity	Physics / storage	Money	Latent capacity, release conditions, potential

Dreamineering’s best source domains already work this way: navigation, loops and systems, pictures and platforms, instruments. They reorganise the idea; they don’t just embellish it.

The Risk: Metaphor Stacking

The main failure mode is stacking metaphors without grounding. If navigation, loops, dreams, platforms, instruments, sovereignty, and protocols all appear at once, each may be good alone, but together they blur the active transfer. The reader stops completing the mapping.

Rule: One page, one governing metaphor. Supporting metaphors are subordinate to it and reinforce the same transfer. Do not let every interesting metaphor compete equally.

Design Implication

The interface should complete the metaphor, not merely illustrate it. If the page is about navigation, the structure should help users orient, choose paths, and see where they are. If it is about an instrument, interactions should feel precise, responsive, and intentional. The governing metaphor is embodied in the UI — structure, headings, CTAs, and visuals express the same transfer.

Governing Metaphor Checklist

Use this when creating or reviewing homepage, docs, or venture pages.

Per Page

• One governing metaphor — Named and stated early (e.g. “This page is about navigation” or “This is the instrument”).
• Source and target clear — You can state in one sentence what is being transferred and into what.
• Structure supports action — Headings, links, and CTAs use the same metaphor so the reader knows what to do next.
• No ornament-only metaphors — Every metaphor on the page passes the five-question test.
• Navigation completes the metaphor — Wayfinding and next steps feel like the governing metaphor (e.g. “paths,” “steps,” “instrument controls”).

Homepage

• Governing metaphor is obvious in the first screen (e.g. “two paths,” “loop,” “system”).
• Section order and labels reinforce one transfer (e.g. enemy → problem → loop → systems → choice).
• CTAs use the same domain language (“Explore the system,” “Start the journey”).

Docs

• Each doc or section has one governing metaphor; subsections support it.
• Cross-links use consistent metaphor (e.g. “See the loop” not “See the article”).
• Glossary and naming align to the metaphor where it matters.

Venture Pages

• The venture’s metaphor (e.g. “board,” “game,” “path”) is named and used in headlines and CTAs.
• Proof and credibility are framed in the same domain (e.g. “moves on the board,” “steps on the path”).

Connection

• Persuasion — Metaphor as transfer structure supports ethos, logos, pathos, kairos, topos
• Tight Five — Same five, different domains; metaphor carries the binding
• Design — Interface that completes the metaphor
• Progress — Pictures, navigation, loops as source domains
• Naming standards — Terms that carry metaphor consistently

Questions

• When two strong metaphors both fit a page, how do you choose the governing one — by conversion goal, by audience, or by existing site metaphor hierarchy?
• How do we audit existing docs for metaphor stack without losing the depth that makes Dreamineering distinctive?
• Should the governing metaphor be explicit in frontmatter or only enforced in structure and copy?