Bridge domains through structural patterns, not surface metaphors — only structure enables inference transfer
When creating bridge nodes between domains, link to structural patterns (diminishing returns, feedback delays, threshold effects) rather than surface metaphors (companies as bodies), because only structural correspondence enables valid inference transfer across contexts.
Why This Is a Rule
Cross-domain bridge nodes are the most valuable links in a knowledge graph — they connect insights from one domain to another, enabling inference transfer. But the value depends entirely on whether the bridge is structural or metaphorical.
Structural bridges connect through shared relational patterns: "Team scaling in engineering follows the same diminishing-returns curve as adding servers to a distributed system." Both domains share the structure: increasing quantity produces sub-linear returns due to coordination overhead. Inferences from one domain transfer validly because the structure is shared (Cross-domain patterns must share causal structure, not surface vocabulary).
Surface metaphor bridges connect through superficial resemblance: "A company is like a body — the CEO is the brain, departments are organs." This feels insightful but enables no valid inference. Companies don't metabolize, organs don't have KPIs, and the metaphor breaks immediately when you try to transfer specific conclusions from biology to management.
The test: can you transfer a specific inference from Domain A to Domain B through the bridge? If yes → structural bridge (keep). If you can only transfer vague impressions → surface metaphor (delete or downgrade).
When This Fires
- When creating cross-domain links in your knowledge graph (Prioritize cross-domain links over within-cluster links — weak ties generate better insights)
- When a connection between domains "feels right" but you're not sure it's useful
- During any analogical reasoning where insights from one domain inform another
- When evaluating whether an analogy enables genuine prediction or just feels clever
Common Failure Mode
Creating metaphor bridges because they feel insightful: "Knowledge management is like gardening!" The metaphor is aesthetically pleasing but structurally empty — you can't transfer specific gardening techniques to knowledge management because the structures don't match. A structural bridge: "Knowledge bases accumulate maintenance debt at the same compound rate as codebases, governed by the same interaction between complexity growth and capacity constraints." This enables specific inference transfer.
The Protocol
When creating a cross-domain bridge: (1) Identify the structural pattern shared by both domains — not vocabulary, not aesthetics, but relational structure (same dynamics, same constraints, same failure modes). (2) Test transferability: can you take a specific insight from Domain A and apply it validly to Domain B through this bridge? (3) If yes → structural bridge. Create the link with a label identifying the shared pattern. (4) If no → surface metaphor. Don't create the link — it will produce confident but invalid cross-domain inferences.