The vocabulary
So far we have described an architecture (workspaces, a map, communications, a person at the center), shown how boundaries repeat at every scale, and seen how the parts relate like organs in a body. What remains is the question that makes the difference between an information system and a knowledge system: how do you make the connections mean something?
The problem with links
Every modern note-taking tool lets you create links between notes. Click a word, point it to another note, done. The graph view lights up with connections. It looks like knowledge.
It is not.
A link says “these two things are connected.” It does not say how. It does not say why. It does not say what follows from the connection. A link between “Project Alpha” and “Budget Q3” could mean “this project is funded by this budget,” or “this project exceeded this budget,” or “someone mentioned both in the same meeting.” The link carries no information about its nature.
This is the difference between topology and semantics. Topology tells you the shape of the connections: what is linked to what, how many links, how many hops between two nodes. Semantics tells you the meaning: what kind of relationship, in which direction, with what implications.
A map of a city with only roads and no labels is topology. You can see that places are connected, but you do not know if a road is a highway or a pedestrian path, if it goes north or south, if it is one-way or two-way. The structure is visible; the meaning is not.
The shift from links to relationships is the shift from information to knowledge. A link says “connected.” A relationship says “A funds B, which implies that if A is cut, B must find a new source.” The relationship carries consequences. That is what makes it knowledge.
Why words matter
To describe a relationship, you need words. Specific words. And this is where most systems fail, not for lack of technology, but for lack of precision.
Consider the word “workspace.” In a file system, it means a folder. In Slack, it means an organizational account. In VS Code, it means a set of open projects. In Notion, it means a top-level container for pages. Each tool uses the same word to mean a different thing, and when you move between tools, you carry the ambiguity with you.
Now consider the word “project.” Is a project a folder? A task list? A goal? A collection of documents? A team? Every tool has its own answer, and none of them are explicit about it. You learn what “project” means in Asana by using Asana. You learn what it means in Basecamp by using Basecamp. The definitions are implicit, locked inside each tool's behavior.
This ambiguity is not a minor inconvenience. It is the reason integrations fail. When Zapier copies a “task” from Asana to Trello, it copies data fields. It does not copy what “task” means in each system, because neither system has made that meaning explicit. The integration moves information; it does not transfer understanding.
When a tool does not define its terms, it is not being flexible; it is being opaque. You cannot question a definition you cannot see. You cannot adapt a structure you cannot name. The first step toward a system that adapts to your perspective is making the vocabulary visible and explicit.
A shared dictionary
The solution is old. It predates computing by millennia. It is a vocabulary: a set of terms, each with a precise definition, organized so that the relationships between terms are as explicit as the terms themselves.
In this architecture, the vocabulary is not a glossary in an appendix. It is a structural layer. Every entity in the system has a type, and the type comes from the vocabulary. Every relationship has a name, and the name comes from the vocabulary. When the map says “this person collaborates with that person in this workspace,” the words “collaborates with” are not free text; they are a defined term with a specific meaning, a specific domain (what kind of entity can collaborate), and a specific range (what kind of entity can be collaborated with).
This is not bureaucracy. It is the mechanism that turns links into relationships. Without a vocabulary, “A is connected to B” is all you can say. With a vocabulary, you can say “A funds B” or “A inhabits B” or “A elaborates on B,” and each of those statements carries different implications.
Why Latin
The vocabulary we have been using in this system uses Latin terms. This is not aesthetic; it is functional.
English words carry too much baggage. “Workspace” means different things in different tools. “Agent” means different things in AI, in business, and in philosophy. “Trust” means different things in law, in psychology, and in engineering. Every English word arrives with a cloud of connotations from prior use, and those connotations create ambiguity.
Latin terms arrive clean. When you encounter the word satelles for the first time, you have no preconceptions about what it means in Notion or Slack. You learn its definition in this system, and that definition is the only one it has. Satelles means a registered workspace that orbits the person at the center. Period.
This is the same principle that drives scientific nomenclature. Biologists do not argue about what “cat” means because they use Felis catus. Chemists do not argue about what “water” means because they use H2O. Precision is not elitism; it is clarity across contexts.
The vocabulary is not imposed by a vendor. It is defined in the system, by the person who uses it. The base vocabulary provides the essential terms (types of workspaces, types of relationships, types of agents), but you can extend it with terms specific to your domain. A researcher can add terms for their field. A creative practitioner can add terms for their practice. The vocabulary grows with you, and it remains yours.
The machine layer
A vocabulary that only humans can read is a glossary. A vocabulary that machines can also read is an ontology. The difference matters.
When every term in your vocabulary has a formal definition (what it is, what it relates to, what it implies), and when every entity in your system is described using those terms, the system can do more than retrieve information. It can reason about it.
An information system can answer: “Who collaborates with me?” (list the entities with a collaborates with relationship). That is a query. A database can do it.
A knowledge system can answer questions that require perspective, context, and the ability to traverse relationships with meaning:
- “Which of my collaborations is losing momentum, and why?” (requires combining the density of recent interactions, the state of shared projects, and the pattern of communication across channels; “momentum” is not a field in a database, it is a judgment that emerges from the structure)
- “If I start a new project on this topic, who in my system has the most relevant context, and through which workspace should I reach them?” (requires understanding that relevance is not keyword overlap but shared gravitational pull: how many typed relationships connect that person to this topic, through which workspaces, with what kind of involvement)
- “What am I neglecting?” (requires seeing the absence: workspaces with no recent activity, collaborations where the communication flow has gone quiet, ideas that were seeded but never cultivated; the system can surface what is not happening, because the vocabulary defines what should be there)
These are not search queries. They are questions that only make sense when the system understands what things are, how they relate, and from whose perspective the question is being asked.
The system achieves this by representing the vocabulary and all registry data in a format that follows established semantic web standards. Each term maps to a formal definition. Each relationship maps to a typed property. The human reads notes in plain language; the machine reads the same information in structured form. Two interfaces, one truth.
The vocabulary is not documentation. It is infrastructure. Without it, you have files with links: an information system. With it, you have entities with typed relationships, organized from a defined perspective: a knowledge system. The vocabulary is the upgrade from DIKW's “information” layer to its “knowledge” layer.
Precision as freedom
There is a common objection: “This sounds rigid. I do not want to define every term before I can take a note.”
The objection misunderstands the role of the vocabulary. You do not need to classify everything. You do not need to define a term for every concept you encounter. The vocabulary exists for the relationships that matter: the structural connections that organize your system, the types that determine how things behave, the terms that your agents need to understand in order to help you.
Your daily notes, your quick captures, your rough drafts: these remain free text. The vocabulary governs the architecture, not the content. It is the difference between a city's zoning plan and the conversations people have in their houses. The plan defines what kinds of buildings go where; it does not prescribe what happens inside them.
And here is the paradox: precision creates freedom. When the structural terms are well-defined, everything else can be loose. You do not need to tag every note, because the relationships between entities already carry the meaning. You do not need to organize every file into the “right” folder, because the registry already knows what things are and how they connect. The vocabulary handles the architecture; you handle the thinking.
Previous: The living system | Next: The whole