---
name: Relationship Mapping
status: draft
territory: structural-relationship-mapping
msi_territory: structural-relationships
sources:
  - title: "Wasserman, Stanley & Faust, Katherine (1994), Social Network Analysis: Methods and Applications, Cambridge University Press"
    url: https://openlibrary.org/works/OL3486325W
  - title: "Burt, Ronald S. (1992), Structural Holes: The Social Structure of Competition, Harvard University Press"
    url: https://openlibrary.org/works/OL4120645W
  - title: Granovetter, Mark S. (1973), The Strength of Weak Ties, American Journal of Sociology 78(6):1360–1380
    url: https://doi.org/10.1086/225469
---

# Relationship Mapping

## Why it matters

When you are trying to understand something with a lot of moving parts — an industry, an organization, a regulatory fight, a tangle of people and money — the instinct is to make a list. List the players, list the facts, and the situation feels handled. But a list throws away the one thing that usually matters most: how the parts connect. The same set of players arranged two different ways behaves in two completely different ways. Relationship mapping is the discipline of drawing the connections — laying the parts out as a network and reading the *shape* of that network, because the shape tells you things no list ever can.

For example: take six AI labs and three cloud providers and you can list all nine. But map who has an equity stake in whom, whose models run on whose compute, where the talent flows — and a structure appears that the list hid completely. One cloud provider turns out to sit between two labs that have no direct tie, quietly able to broker or block what passes between them. One lab depends on a single provider for compute, so that one edge, if it snapped, would strand the whole operation. A cluster of three forms a tight bloc; a fourth player sits alone, connected to everyone but belonging to no group. None of that is visible in the list of nine. All of it jumps out of the map.

- **What it reveals.** The structure hidden inside a set of connected things — who the hubs are, who the brokers are, which single connections are load-bearing, where the tight clusters and the empty gaps sit, and how an effect would travel through the web. Properties of the *arrangement*, not of any one part.
- **How it changes the read.** You stop asking *"who are the players and what are the facts?"* and start asking *"how is this wired, and what does the wiring make possible or inevitable?"* — because position in the structure often matters more than any single actor's attributes.
- **When to foreground it.** A situation whose difficulty is *relational* — many entities whose connections, dependencies, and influence on each other are the heart of the question — and you have it described in words, not yet drawn as a diagram.
- **What you'd miss without it.** The broker who controls a flow without owning anything; the single dependency whose failure cascades; the structural gap that is an opportunity or a blind spot. A list of parts cannot show you a property that only exists in how the parts are joined.
- **Where it misleads.** Pushed past its limits it draws tidy static maps of things that are actually dynamic — feedback loops, flows over time — and a clean diagram can lend false confidence to connections that are inferred rather than confirmed. The map is as good as the edges you can defend.

## Realtime examples

See real, dated analyses where this mode drew out the structure behind a story in the news → **[Relationship Mapping on Main Street Independent](https://mainstreetindependent.com/analyses/technique/structural-relationships/relationship-mapping)**

## How to invoke it in Ora

You have a situation whose difficulty is *relational* — a set of people, organizations, or concepts whose connections and dependencies are the heart of the question — and you have it in words rather than already drawn as a diagram.

Describe the entities and how they relate, and ask:

> "Draw me a relationship map of how [these players] connect — who depends on whom, what affects what. A dependency graph."

The phrases *relationship map*, *how these connect*, *who depends on whom / what affects what*, and *dependency graph* are what route you here. Bring the situation concretely — naming the entities and the *kinds* of connection that matter (a stake, a contract, a reporting line, a flow of information) gives the map a far stronger start; the mode will surface the entities and connections you missed, but it works best from a real description rather than "map this industry for me."

Two boundaries worth knowing. If the situation is really driven by feedback loops — A pushes B, B pushes C, C loops back and changes A — that is a dynamics question, and the systems-dynamics modes fit better than a static map. And if you already have a diagram and your question is "what's missing from this picture," that is the visual-input sibling's job, not this one. This mode turns a description into a structure you can read; it does not animate the structure over time.

## How it works

The clearest way to see what relationship mapping does is to watch it turn a paragraph into a picture. Suppose you write down how your organization works: a product team that decides what to build, an engineering team that builds it, a design team that owns the look, a research team that informs both, a customer-success team that hears user pain, an executive layer above them, and a board above that. Engineering depends on design for specs and on product for priorities. Customer success funnels issues to product, which passes work to engineering. Research feeds product, but also goes straight to design. As prose it reads fine. As a structure it has features you cannot see in the prose at all.

The move is simple and it is the whole method: lay out the entities as **nodes** — dots on a page — and draw the relationships between them as **edges** — lines connecting the dots. People, organizations, concepts, components: all nodes. Stakes, dependencies, flows of information, lines of influence: all edges. And it helps enormously to label each edge with the *kind* of connection it is — a dependency is not the same as a flow is not the same as a mere correlation — so the picture stays readable instead of collapsing into one undifferentiated tangle. Once it is drawn, the shape starts talking. Three readings do most of the work.

The first is **centrality** — who is connected to the connected. Not just who has the most lines, but who sits where the traffic concentrates. In the org map, product turns out to be the hub: nearly everything routes through it, which means product is both the place leverage lives and the place that jams first under load. A node can have only a few connections and still be central if those connections are themselves to central nodes. Centrality is the formal answer to "who actually matters here," and it routinely names someone the org chart does not.

The second, and the most counterintuitive, is **brokerage** — who bridges otherwise-separate groups. The sociologist Mark Granovetter called this "the strength of weak ties": the connection that matters most is often not the strong bond inside your tight circle, where everyone already knows everyone, but the *weak* tie that reaches across to a different circle entirely. The person standing in that gap — Ronald Burt named the gap itself a "structural hole" — controls what passes between the two sides, hears things first, and can combine what neither side can combine alone. On a map the broker is obvious: pluck them out and the network falls into pieces. In a list they are invisible, because brokerage is not a property a person *has*; it is a property of *where they sit*.

The third is **clustering** — where the network thickens into tight-knit groups and where it thins into gaps. Dense clusters share information fast and think alike, which is a strength and a blind spot at once. The empty spaces between clusters — the structural holes — are where the brokers live and where the unexploited opportunities sit. Reading the clusters tells you where ideas will and won't travel, and where adding a single connection would change the most.

That is the entire discipline: nodes, edges, and then read the structure for its hubs, its brokers, and its clusters. Whether the thing being mapped is a stakeholder network around a decision, a concept map of how ideas in a field connect, or a dependency graph of which components rely on which, the payoff is the same — a property that exists only in the *arrangement* of the parts, and which no amount of staring at the parts one by one would ever reveal. The honest version of the method carries one more discipline with it: it labels an edge by the *weakest* relationship the evidence actually supports — "these two move together" rather than "this one causes that one," unless the stronger claim is earned — because the fastest way to lie with a network diagram is to draw confident arrows you cannot defend.

## Framework & implementation

*This section uses Ora's own terms for the parts of an analysis, so that if you open the actual mode file they line up. Each is glossed in plain language on first use.*

### Pipeline execution

Relationship Mapping is the general, text-input **mode** in the **structural-relationship-mapping** territory — the operation for turning a written description of a situation into a typed relationship graph. (Its sibling in the territory, spatial-reasoning, handles the same work when the input is a *diagram* instead of prose.) It runs at **Gear 4**, Ora's most thorough setting: a **Depth analyst** and a **Breadth analyst** build the map in parallel and then critique each other (**cross-adversarial evaluation**) before a consolidator integrates the result — depth pushes each connection to the type and direction the evidence supports, breadth guards against the entities and edges a single pass would miss.

The pass does four things in order. It **builds the entity inventory** — the elements whose relations matter, with deliberate attention to the ones that are easy to miss: intermediaries, conditioning factors, downstream-affected parties, controlling structures. It **chooses the relation typology** that fits the question — a question about regulatory dependency wants different edge types than one about causal influence or reporting structure, so the mode picks the vocabulary (causal, correlational, dependency, influential, structural) rather than imposing a fixed schema, defaulting to the *weakest* type the evidence supports. It **constructs the graph** with attention to the structural features the question turns on — central nodes (high-degree or high-betweenness), strongly connected subgroups, the focal entity-pair, and the missing edges the description implies but does not state. Finally it **surfaces the structural observations** the graph makes visible — the hub, the broker, the dense core, the gap the user did not see — and runs an explicit **acyclicity check**, because a cycle is the signal that the situation is really about feedback dynamics and belongs in a systems-dynamics mode.

The mode's reasoning tools ride in its **`ANALYTICAL PERSPECTIVES`** block — the lenses it loads as it works. Two are *hosted* here, meaning this mode is their public home: the **niches** lens (competitive-position reading — where a player can thrive because few others occupy that spot, drawn from the competitive-exclusion tradition) and the **scale** lens (how a structure's properties change as it grows or shrinks, so that what was a strength at one size becomes a liability at another). Both are at home in structural work: a relationship map is exactly where you can *see* an entity's niche in the network and reason about how the whole structure behaves as it scales. The territory's own disciplines — the typed-connection requirement, the acyclicity guard, and the Novak-style cross-link requirement (a genuine concept map carries at least one link bridging two otherwise-separate sub-trees, the marker that the mapper has seen something the standard taxonomy does not assert) — sit alongside them.

### Output contract

The deliverable is a fixed set of sections, so the map is auditable rather than a loose sketch: **Focal Question** (the relational question the map answers), **Entities** (each node named, with its role in the structure stated), **Connections with Type and Directionality** (every edge labeled by relation type and by direction — one-way or mutual — with the weakest type the evidence supports), **Organising Structure** (the overall shape named explicitly — hub-and-spoke, chain, hierarchy, network, bipartite — and what that shape implies), **Key Relationships** (the load-bearing edges, each with why it matters and whether it is obvious or non-obvious — this is where the hubs, brokers, and structural holes are called out), a **Boundary Statement** (what the map deliberately does not cover, and which adjacent map would cover it), and an **Acyclicity Check** (whether the graph is loop-free, and if not, the explicit hand-off to the systems-dynamics modes for the cycles found).

### Origin and evidence

The reading disciplines come from social network analysis, the field that made "structure is a property of the connections, not the nodes" rigorous. Stanley Wasserman and Katherine Faust's *Social Network Analysis: Methods and Applications* (1994) is the standard reference for the formal machinery — the centrality measures (who is connected to the connected), connectivity, and community detection — that lets a map be read rather than merely drawn. Mark Granovetter's "The Strength of Weak Ties" (1973) supplied the central, counterintuitive result that the bridging connection across groups often matters more than the strong bond within one — the foundation of the brokerage reading. Ronald Burt's *Structural Holes: The Social Structure of Competition* (1992) named the gaps between clusters and showed why the player who spans them holds a structural advantage. Underneath all three sits graph theory, which provides the node-and-edge formalism itself, and alongside them the concept-mapping tradition (Novak) that contributes the cross-link discipline for mapping ideas rather than people.

### Applications and common uses

- **Stakeholder and organizational structure.** Who influences whom, who depends on whom, where the real hub and the real broker sit — frequently a different picture than the formal org chart.
- **Industry and market structure.** Equity stakes, supply and compute dependencies, talent flows, and licensing ties among a set of firms — the dependency graph that shows who is load-bearing and who is exposed.
- **Concept mapping.** Laying out the ideas in a field and the typed links between them, with cross-links the standard taxonomy does not assert — a tool for understanding and for pre-writing.
- **Dependency and architecture graphs.** Which components, services, or teams rely on which, so the single-point-of-failure edge and the tightly-coupled cluster become visible before they break.
- **Political and policy networks.** Who knows whom, who staffed whom, what flows through where — tracing the structure of a personnel-and-influence system across an institution.

### Failure modes and when not to use it

- **Confident arrows you cannot defend.** The fastest way to mislead with a network is to draw a *causal* edge where you only have *correlation*. The mode defaults every edge to the weakest type the evidence supports and flags the rest.
- **The static-snapshot trap.** A clean diagram can hide that the situation is actually dynamic. When the map contains cycles, that is not a tidy detail to flatten — it is the signal to switch to a dynamics mode, and the acyclicity check exists to force that recognition rather than smuggle the loop into a static picture.
- **Mistaking the map for the analysis.** The structure is *input* to a decision, not the decision. The hub it names, the dependency it exposes — those are starting points for the downstream work, not conclusions in themselves.

**When not to reach for it.** When the question is about a *process's flow* — the ordered sequence of steps something moves through over time — that is **process-mapping**, not a static relationship graph. When the question is about a system's **stocks and flows** and the feedback loops that drive its behavior over time, that is **systems-dynamics-structural** (or its causal sibling), the home for exactly the cycles this mode hands off. And when the real question is which stakeholders to *prioritize* by their power and their interest in an outcome, the **stakeholder-mapping** power/interest grid is the purpose-built tool — relationship mapping shows you the whole web of who-connects-to-whom, but it is not the prioritization grid.

## Related

- **Spatial Reasoning** — the visual-input sibling in the same territory: when you already have a diagram and the question is "what's missing, ambiguous, or off about this picture," not "turn this description into a structure."
- **Systems Dynamics (Structural)** — the mode for when the situation runs on feedback loops and stocks and flows rather than a static web — the boundary this mode hands off across whenever its acyclicity check finds a cycle.
- **Process Mapping** — the sibling for when the question is a sequence of steps over time, a flow rather than a structure of connections.
- **Niches** and **Scale** — the two lenses this mode hosts: reading where a player can thrive in the structure because few others occupy that spot, and how the structure's behavior changes as it grows or shrinks.

## Sources

- [Wasserman, Stanley & Faust, Katherine (1994), Social Network Analysis: Methods and Applications, Cambridge University Press](https://openlibrary.org/works/OL3486325W)
- [Burt, Ronald S. (1992), Structural Holes: The Social Structure of Competition, Harvard University Press](https://openlibrary.org/works/OL4120645W)
- [Granovetter, Mark S. (1973), The Strength of Weak Ties, American Journal of Sociology 78(6):1360–1380](https://doi.org/10.1086/225469)