Chapter 11

What Are Nodes and Edges

Chapter 10 divided memory into five kinds of Node and one open carrier. This chapter looks at what that division actually does, and why an Edge, the relation that joins two Nodes, is never just a line.

1. A Node is a contract, not a label

Writing “Concept” on a Node and that Node actually being treated as a Concept are two different things.

If a Node is a Concept, it is referred to again and again, retrieval puts it forward as a candidate and settles on it, and it forms relations with other Concepts. If it is an Episode, it is an event recalled in time order. Retrieval can name an Episode too, but what it names then is a moment rather than a meaning, and the system handles the two differently.

So a Node's kind is not decoration. It is a contract, fixed in advance, about how that Node will be handled inside the system. Label something a Concept and treat it like an Episode, or the reverse, and retrieval and traversal drift apart.

2. Five kinds, each answering a different question

• Concept: what does this mean? The meaning that is true now.
• Decision: what was chosen? The judgment made then.
• Record: what was observed or confirmed? The record that serves as evidence.
• Episode: what happened, and when? An event on the timeline.
• Bridge: where do separate domains meet? A connection point.

A single sentence, “we decided to adopt a new vector database”, has three kinds tangled in it: the concept of that database (Concept), the choice to use it (Decision), and the circumstances at the moment of the choice (Episode). Store all three as one block and “why did we pick this technology back then” becomes hard to answer. Split them by kind and you go straight to the piece the question needs.

The five are closed. The system defines them and handles each in its own way. One thing is open: Entity. Whatever a person authors under a name outside the five lands on Entity under exactly the type name they chose. That name is not accepted as fact; it enters their vocabulary as a proposal. Ratifying it, rejecting it, or renaming it is a person's act. Chapter 13 takes up that vocabulary.

3. An Edge carries direction and meaning together

That two Nodes are connected is not enough information on its own. Whether A caused B, whether A is a condition that has to hold before B, or whether they are merely related are entirely different claims.

So an Edge has a name and a direction.

A ──prerequisite_of──> B

This does not say A and B are linked. It makes a specific claim: A has to be in place before B. Reverse the direction and it is a different claim.

The relations a person writes are six.

• relates_to: loose association.
• prerequisite_of: precondition.
• derives_from: derivation.
• inherits_from: inheritance.
• about: what something concerns. Used when an Episode or a Decision points at a Concept or a Decision.
• connects_via: used when a Bridge crosses a domain to reach a Concept.

The vocabulary is kept narrow on purpose. Every new relation name is one more thing everyone has to agree on again: what exactly does this mean?

Beyond these six, the system makes three relations of its own. MENTIONS records that a chunk of a document named a Concept (Chapter 12). ATTACHES_TO carries a Record onto a Concept or Decision while preserving the relation name the writer used. TYPED carries the chosen type name between one Entity and another. A person writes six; the rest are how those six are stored.

4. Allowed pairs

Not every kind connects to every other kind through any relation. The allowed pairs are fixed, the server and the tool hold the same table byte for byte, and a test keeps them equal.

Concept and Decision are interchangeable almost everywhere. There is one exception. relates_to exists only between Concept and Concept. A Decision is not vaguely related to something; it is about a Concept, and Decisions are chained to one another by lineage, one superseding another.

Without this constraint a graph can look dense and say nothing. A graph where everything connects to everything through relates_to is a graph that draws no distinctions at all. Send a pair that is not allowed and the system does not quietly store it; it returns a warning. That contract is Chapter 14.

5. Why Node and Edge are kept apart

In short: a Node fixes what exists, and an Edge fixes in what capacity those things meet.

Keeping the two apart sharpens the questions the graph can answer. Not “everything related to this concept”, but “what had to exist before this concept”, “what derived from it”, “which decision this decision replaced”.

The next chapter looks at how these Nodes and Edges connect back to the source document: how the graph holds onto meaning drawn from a document without replacing the document itself.

Continue with Chapter 12, How Documents and the Graph Connect.