Foundational Chapter 4
Relationships Are Data
"Most systems lovingly model their nouns and treat the verbs between them as an afterthought. The verbs were the point."
— Rick Collette
Abstract
Most data models lovingly describe the nouns and shrug at the verbs.
The user. The product. The document. Each modeled with care — attributes, lifecycle, validation. The connections between them? A foreign key. A join table. An afterthought. And for a large and growing class of systems, the connections were the entire point.
The first three laws concerned truth, constraints, and security — the foundations any system needs. This law is about a modeling failure so common it is nearly invisible: the habit of treating the connections between entities as second-class, derived from the entities rather than data in their own right.
Most systems are built entity-first. The user is an object, the product is an object, the document is an object — each modeled with care, each given attributes, lifecycle, and validation. The relationships between them — who follows whom, who owns what, what depends on what, what grounds what — are relegated to foreign keys, join tables, and implicit conventions, modeled as thin links between the "real" things. For a large and growing class of systems, this is exactly backwards. The relationships are the real things, and the entities are the endpoints.
This chapter argues that relationships are data — first-class, attributed, with their own truth, lifecycle, and meaning — and that systems whose value lives in connections must model those connections as deliberately as they model anything else. It grounds the argument in Ampriot, a platform built relationship-first; in AISDR, whose evidence and threat models are fundamentally graphs of relationships; and in SADIE, whose work is coordinated by a graph of dependencies. It also reconciles this law with the first: relationships are truth, and graphs are how that truth is projected.
1. The idea
A relationship is not the absence of space between two entities. It is a thing, with its own existence, attributes, and history.
"Alice follows Bob" is not merely a row that points Alice at Bob. It has a direction (Alice → Bob, not Bob → Alice). It has a moment of creation and possibly of ending. It may have a weight (how strongly, how recently, how actively). It may have a type (follow versus block versus collaborate). It may carry its own permissions and its own audit trail. Treated as a first-class datum, the relationship can be reasoned about, queried, attributed, and governed. Treated as a foreign key, all of that richness is either lost or smeared awkwardly across the entities it connects.
The entity-first habit comes from a real place: relational databases, object models, and most of our teaching center the noun. Tables are named for entities; classes are named for entities; APIs are organized around entities. Relationships fall out as join tables and reference fields — structurally present, conceptually invisible. This works fine when the relationships genuinely are incidental. It fails, sometimes catastrophically, when the relationships are the product.
And increasingly they are the product. A social platform is its follow graph. A recommendation system is its affinity graph. A security knowledge base is its graph of vulnerabilities, techniques, and mitigations. A workflow engine is its dependency graph. A knowledge platform is its citation graph. For these systems, modeling the entities beautifully and the relationships as an afterthought is modeling everything except the thing that matters. The law is a correction: when connections carry the value, give them the status of data.
2. The forces
Value migrates to the edges. In a maturing system, the entities often commoditize and the relationships accrue the value. Any platform can store users; what makes a social platform valuable is the graph of who is connected to whom. Any system can store documents; what makes a knowledge system valuable is how they relate. As a system matures, more and more of its differentiating value lives in edges, not nodes — and value that lives in the edges must be modeled in the edges.
Relationships have their own richness. Direction, type, weight, recency, strength, permissions, provenance, lifecycle — these are properties of the relationship, not of either endpoint. "Alice supported Bob's release, on this date, at this tier, which lapsed last month" is information that belongs to the connection. Forced into the entities, it distorts them; forced into a bare join row, it is lost. First-class relationships have somewhere to put it.
Questions are relationship-shaped. The interesting questions in these systems are traversals: who is two hops from Alice, what techniques exploit this vulnerability and what mitigates them, which tasks transitively block this one. These questions are awkward or ruinously expensive against an entity-first schema and natural against a model that treats relationships as data. The shape of the questions a system must answer is itself an argument for how its relationships should be modeled.
The pull-back force: relationships are truth, and must obey the first law. This law does not contradict Chapter 1; it specializes it. A relationship that matters — ownership, a granted right, a follow that gates access — is a truth-plane fact, and it must have one home like any other truth. The richness and queryability of relationships tempt teams to let the graph become the authoritative store of connections, which would give relationships two homes (the graph and the relational truth) and reintroduce exactly the ambiguity Chapter 1 warned against. The resolution is the one Chapter 1 already gave: the truth of a relationship lives in the Truth Plane; the graph is a projection that makes it traversable.
3. The law
Relationships between entities are first-class data — attributed, directional, with their own lifecycle and meaning. Systems whose value lives in connections must model those connections as deliberately as they model entities, while keeping the truth of each relationship in one authoritative home.
Two corollaries follow:
Model the edge, not just the endpoints. A relationship's own attributes — type, direction, weight, time, provenance, permissions — belong to the relationship and must have a place to live.
Truth in the relational home, traversal in the graph. The authoritative record of a consequential relationship is a Truth Plane fact; the graph is a projection of it, kept for the questions that are relationship-shaped. (Chapter 1, applied to edges.)
Ampriot, AISDR, and SADIE each make relationships first-class in a different domain.
4. Implementation: Ampriot, built relationship-first
Ampriot is, by its own description, a relationship-first platform — and the ordering of that phrase is the architectural thesis. It does not model artists and listeners and then add connections between them as a feature. It treats the connections — who supports whom, who collaborates with whom, who is connected to whom and how — as the primary data the platform exists to manage, and treats the entities as the things those connections relate.
This ordering shows up directly in the plane architecture from Chapter 1. The authoritative relationships — follows, ownership, support, rights — live in MariaDB, the Truth Plane, as first-class facts with their own lifecycle: created, modified, ended, each change an explicit business operation, each carrying its own attributes and audit. They are not incidental join rows; they are records the platform reasons about, governs, and treats as truth.
And then, exactly as the second corollary requires, Ampriot maintains a graph layer as a projection of those relationships — a read model rebuilt from MariaDB and kept current by the NATS event spine, existing specifically to answer the relationship-shaped questions a relational schema serves poorly: traversals, affinities, multi-hop discovery. The graph is where relationships are queried; MariaDB is where they are true. This is the synthesis the law demands: relationships modeled as first-class data, given the richness and queryability of a graph, without ever letting the graph become a second home for the truth of who is connected to whom.
The recommendation engine then sits on top of the graph (Chapter 1's Intelligence Plane), turning the relationship structure into discovery. Notice the layering this produces, all flowing from taking relationships seriously: relationships are truth in MariaDB, structure in the graph projection, and insight in the recommendation engine. An entity-first design would have buried the relationships in foreign keys and made every one of those layers harder. Ampriot's value — relationship-driven discovery and commerce — is downstream of the decision to treat relationships as the primary data from the start.
5. Implementation: AISDR, where the domain is a graph
AISDR shows that this law reaches well beyond social platforms. Its entire problem domain — security knowledge — is natively a graph of relationships, and AISDR models it as one.
The clearest case is its hybrid retrieval, which includes graph traversal over the relationships of the threat domain: CVE → MITRE ATT&CK technique → mitigation. The value here is not in the nodes individually — a CVE record, a technique, a mitigation — but in the edges between them. "What techniques exploit this vulnerability, and what mitigates them" is a pure relationship traversal, and it is exactly the question a security analyst needs answered. Modeling vulnerabilities, techniques, and mitigations as isolated entities and hoping to join them on demand would miss the point; the connections are the knowledge.
AISDR's evidence model is relationship data of another kind. A decision is grounded in sources; a source supports or contradicts a recommendation; an evidence bundle links a decision to the precise sources that informed it. These "grounded-in," "supports," and "links-to" connections are first-class — they are what make a decision auditable and replayable six months later. The provenance of evidence is a graph of relationships between decisions and sources, and AISDR treats those relationships as data to be recorded, preserved, and traversed, not as incidental references.
Even AISDR's agent-runtime security is relationship-aware: a tool descriptor's hash is bound to its approval — an "approved-as" relationship between a specific tool definition and a specific authorization — and a change to the tool breaks that relationship and forces re-approval. The security property from Chapter 3 is, underneath, the integrity of a modeled relationship between what was approved and what runs.
And consistent with the pull-back force: where these relationships are consequential — which decision was grounded in which approved source, who authorized which tool — they live in AISDR's immutable, truth-plane records. The graph traversal accelerates finding relationships; the authoritative relationships themselves are truth. The law and the first law cohere.
6. Implementation: SADIE, work as a dependency graph
SADIE rounds out the picture by showing relationships as the structure of coordination. Its workflows are not flat lists of tasks; they are graphs, and the edges — the dependencies between tasks — are first-class data that the engine reasons about directly.
A task in SADIE has dependencies: other tasks that must complete before it can become ready. Those dependency relationships are modeled explicitly, with their own meaning (finish-to-start and other dependency types), and they are what the worker traverses to decide what is runnable now. "What is ready to run" is a graph computation over the dependency edges; "what is blocking this" is a traversal in the other direction. The relationships between tasks are not implied by ordering or convention — they are data, and the entire scheduling behavior of the system is a function of that data.
This is the law in its least glamorous and most universal form. SADIE is not a social network or a knowledge graph; it is a workflow engine. And yet its correctness and its behavior depend on treating the connections between tasks as carefully modeled, first-class data — directional, typed, with their own lifecycle — rather than as an afterthought to the tasks. Wherever work has structure, that structure is relationships, and relationships are data.
7. The failure modes
Relationships as afterthoughts. The entity-first default taken where it does not belong: rich entity models, and connections shoved into bare foreign keys and join tables with no attributes, no lifecycle, no first-class existence. The system can store that Alice and Bob are connected but cannot say when, how strongly, in what direction, or with what history — because the relationship was never given a place to hold its own data. When the product turns out to be the connections, the model has nowhere to grow.
The graph that became truth. The mirror-image failure, and the one this law must guard against most carefully: making relationships first-class by writing them only to the graph, so the graph becomes the authoritative store of connections. Now relationships have two homes (or worse, only the graph), and Chapter 1's truth-ownership problem returns at the level of edges. The discipline is the second corollary: truth of the relationship in the relational home, graph as projection.
Entity-shaped answers to relationship-shaped questions. Forcing traversal questions — multi-hop reachability, transitive dependencies, affinity — through a schema optimized for entity lookup. The queries become monstrous joins or N+1 cascades, and performance collapses as the graph grows. The questions were relationship-shaped; the model should have been too, via a projection built for traversal.
Lossy relationships. Modeling the existence of a connection but discarding its attributes — recording that a support happened but not at what tier, that a task depends on another but not how, that a decision used a source but not whether it supported or contradicted. The edge is half-modeled, and the discarded half is often exactly the part that mattered. Model the edge fully, not just its existence.
8. The tradeoffs
Treating relationships as first-class data costs modeling effort and operational surface. A foreign key is nearly free; a first-class, attributed, lifecycle-bearing relationship — plus a graph projection to make it traversable — is real design and real infrastructure. For a system whose connections genuinely are incidental, that investment is waste: an accounting ledger does not need a follow graph, and dressing up its foreign keys as first-class relationships would add cost for no value. The law is not "always build a graph." It is "recognize when connections carry the value, and model them accordingly."
The harder tradeoff is the one this law shares with Chapter 1: maintaining relationships as truth in one home and as a projection for traversal means running both, and keeping the projection honestly derived. That is the eventual-consistency and reprojection cost from Chapter 1's Projection Plane, paid specifically for edges. It is the right cost for a relationship-first system — it is what lets Ampriot be both correct about who owns what and fast at relationship discovery — but it is a cost, and a system whose relationships do not warrant it should not pay it.
The judgment, consistent with every law so far, is one of matching. Invest in first-class relationships proportionally to how much of the system's value lives in its connections. For Ampriot, AISDR's threat graph, and SADIE's dependencies, that investment is the core of the architecture. For a system whose nouns really are the point, a foreign key is the correct, honest model — and pretending otherwise is its own failure.
9. The future
The trend lines all point toward relationships mattering more, which makes modeling them well a growing advantage.
AI is the strongest driver. Knowledge graphs, retrieval-augmented generation, and graph-based reasoning are, at bottom, machinery for exploiting relationships — and their quality is bounded by how well the underlying relationships are modeled. AISDR's CVE → ATT&CK → mitigation traversal and its evidence-provenance graph are early examples of a general pattern: as AI is asked to reason over a domain, the relationships in that domain become the substrate of the reasoning, and systems that modeled their connections as first-class data will have something to reason over that systems built entity-first will not. The much-discussed pairing of knowledge graphs with language models is, in this chapter's terms, the recognition that relationships are data the model needs.
Distribution and scale push the same way. As systems grow, the entities multiply but the value concentrates in the connections between them — the network effects, the affinities, the dependency structures. The systems that scale into that value are the ones that can traverse their relationships efficiently, which means the ones that projected their relationships into structures built for traversal rather than burying them in joins.
The modeling tools will keep improving — graph databases, vector stores, hybrid retrievers — but the law underneath them is older than any of them and will outlast them. The connections between things are often the most valuable data a system holds. A system that treats them as first-class can reason about them, govern them, and build on them. A system that treats them as the gaps between its "real" objects has thrown away its most important data and called it schema.
The next law moves from how a system models its world to how a system that reasons about that world must be disciplined — the order of operations between knowing and inferring, which the rise of AI has made urgent. Evidence Before Intelligence.