The third part of the series on the three-layer semantic engine. The first — «Where Meaning Lives» (part one), the second — «How to Build a Map of Meaning» (part two).
In the previous part we dealt with the semantic map. Poles emerge from the dynamics of representations, learn through approximate gradients, fight extinction, separate streams and, ideally, give the system stable coordinates to work with context.
But coordinates by themselves are not knowledge.
The map says: "we are in the field of medicine." It does not say: "patient Ivanov is allergic to penicillin, the last blood test was on March 14, the attending physician is Petrova." That is different. Those are facts. And they live by different rules.
In the first article we said that factual knowledge is better moved outside — into a separate structure that can be edited without retraining the model. Now it is time to understand what this means in practice, why a simple graph is insufficient, and how the problem of contradictory knowledge turns into a problem of time.
Why a fact should not live in the weights
Imagine that the system must remember the date of birth of a particular person. In a monolithic model, this fact is distributed across billions of parameters. It does not exist in one place — it is smeared across the whole weight space, like a smell in a room.
This gives enormous capacity. But it creates three problems.
The first is editing. If the date changes, you cannot simply open a row and fix it. You either have to retrain the model or use complex mechanisms of targeted intervention that scale poorly and unpredictably affect neighboring knowledge.
The second is verifiability. You cannot ask the model: "where did you learn this date?" It will not show the source. It will produce an answer with some confidence, but the origin of that answer is hidden inside the computational dynamics.
The third is conflict. If the model simultaneously encounters two contradictory facts, it cannot explicitly say: "here is a contradiction." It will average them, forget one, or start giving different answers depending on context. None of these outcomes is correct.
That is why Layer 3 proposes a different principle. A fact exists explicitly. As a graph node. With properties, connections, a source and a state.
Graph as memory
Instead of "the model somehow knows inside" we get:
Patient: Ivanov
├── allergy → penicillin
├── last test → 2026-03-14
├── attending physician → Petrova
│ │
│ └── specialization → cardiology
└── diagnosis → hypertension
│
└── confirmed → 2025-11-02
This is a fundamentally different way of handling knowledge. If Ivanov changes doctors, one connection changes. If the test becomes stale, the date is updated. If the diagnosis is removed, the connection is deleted or marked as irrelevant. No retraining.
And here an important property appears, one that parametric memory does not have: the separation of the structure of computation from the content of knowledge. The model does not change when a fact changes. The semantic map is not rebuilt when the user adds a new record. The computational mechanism is stable. The data is not.
This is exactly the boundary we talked about at the end of the second article. Structure changes slowly. Content changes fast. The architecture must draw this boundary automatically.
But the processor does not like graphs
On paper everything looks neat. Nodes, connections, traversal. In practice a physical problem appears.
The processor is optimized for sequential reading: read an address, move to the next, then to the next. That is what the cache, the pipeline and vector instructions are designed for.
The graph says something different. Take a vertex. Look at its neighbors. Jump to an address. Look at the next ones. Leap to a completely different place in memory. Every jump is a potential cache miss, a pipeline stall, lost time.
A naive implementation of graph traversal on a consumer processor can lose up to 90% of performance simply because of the randomness of access. This is not a theoretical estimate — it is what is observed in real graph databases working with large sparse structures.
The solutions are known and partly applied in existing systems. Dense packing of neighbors into sequential arrays so traversal becomes linear reading. Partitioning the graph into local blocks that fit in the cache. Prefetching data before it is needed. Batch processing of several queries at once through vector instructions.
Each technique solves part of the problem. None solves it completely. Their combination can give a 5–10× speedup compared to naive traversal, but the exact gain depends on the graph structure, the size of the working set and the particular processor. This is benchmark territory, not theoretical reasoning.
For this article it is enough to understand the principle: an architectural decision creates a physical problem, and the physical problem is not solved at the level of the mathematical model. At some point mathematics runs into cache lines and bus bandwidth.
The editability paradox
But here a contradiction appears that is easy to miss.
All the optimizations we just discussed assume that the graph is stable. Dense arrays are compiled. Blocks are partitioned. The cache is warm. The system is ready for fast traversal.
And now the user adds a fact.
If every write requires rebuilding the entire structure, performance collapses. Rebuilding a graph with millions of vertices takes seconds or minutes. For an interactive session that is unacceptable.
But if you do not rebuild — the new fact lies somewhere separate, unoptimized, unpacked, and traversal to it will be slow.
This is the editability paradox: the system must be simultaneously stable for fast reading and alive for fast writing.
The solution is to split the graph into two levels. The foundation — a stable, optimized structure that does not change during operation. And on top of it — a change buffer: a compact layer for new and modified connections, optimized for fast writes.
During traversal the system first checks the buffer, then the foundation. Most queries hit the foundation and get full speed. New connections are traversed a little slower, but that is acceptable. A background process periodically merges the buffer into the foundation, re-optimizes it and atomically swaps in the new version. The user sees an instant response. Full optimization happens unnoticed.
This is not a new idea. Modern databases work on the same principle: a fast write-ahead journal on top of an optimized store. A proven pattern, not an experiment.
But the graph stores facts, not knowledge about facts
And here the most interesting part begins.
Imagine that the graph contains a record:
Company X → CEO → Ivan Petrov
This is a fact. But is it enough?
What if Ivan Petrov stopped being CEO three months ago, but the record was not updated? What if the source of this information is a news article with an error? What if another branch of the graph contains another record:
Company X → CEO → Maria Ivanova
Now we have two contradictory statements in one memory. The system must do something with them. But what?
A simple graph gives no answer. It stores connections. But it does not store the system's attitude to these connections. It does not store source, time, degree of trust, scope of applicability.
This means that a graph by itself is not yet memory. It is the skeleton of memory. Living memory requires metadata.
Memory must know when it learned
Let us try to imagine what needs to be added to every fact so the system can work with contradictions meaningfully.
Fact: Company X → CEO → Ivan Petrov ├── source: annual report, 2024 ├── trust: high ├── validity: until a change is confirmed └── conflicts with: [record 2] Fact: Company X → CEO → Maria Ivanova ├── source: press release, March 2026 ├── trust: medium (not independently confirmed) ├── validity: current └── conflicts with: [record 1]
Now the system can reason. Record 2 is newer. Record 1 is confirmed but outdated. Record 2 is fresher but not independently confirmed. Depending on the task, the system can choose one, the other, or escalate: "there is a contradiction, the source is unconfirmed, clarification is required."
This is no longer just a graph. It is a graph with a temporal coordinate, a source and a degree of trust. And it fundamentally changes the nature of Layer 3.
From a fact store it turns into a knowledge management system where every element has a history, a context and a status.
Contradiction is not an error
Here it is important to stop and say one thing explicitly.
In an ordinary database, a contradiction is an error. Two incompatible values in one field mean the data is corrupted. They must be fixed.
In a system working with the real world, contradiction is a normal state. Information comes from different sources, at different times, with different reliability. Facts become stale. Opinions diverge. Context changes.
If the architecture cannot store a contradiction explicitly, it will be forced either to silently pick one version (losing information), or to average (producing nonsense), or to ignore new information (getting stuck in the past). None of these options is correct.
Therefore Layer 3 must be able to store several versions of one fact simultaneously, with an explicit indication of their status. And the task of the system is not to eliminate the contradiction but to present it in a form that lets the higher layer make a decision.
This is directly related to the escalation mechanism we discussed in the context of ethical poles. When Layer 3 detects an unresolvable contradiction, it does not try to resolve it by itself. It forms a request to Layer 2 or to an external operator: "here is a conflict, here are the sources, here are the timestamps, here are the degrees of trust — what should be done?"
The system does not make decisions for the human. It makes the contradiction visible.
Time as the fourth dimension of memory
Looking at all of this as a whole, we find that memory in such an architecture has not three dimensions (entity, property, connection) but four. The fourth is time.
Every fact exists not just as a connection but as a connection at a moment. It was true then. It may be true now. It may be true until some event. It may be true only in a certain context.
This changes the nature of graph traversal. The system does not just look for a connection. It looks for a connection that is relevant for the given moment and the given context. If a connection is outdated, it is not deleted — it is marked. Because an outdated fact may be needed to restore history, for explanation, for audit.
And here another connection to Layer 1 appears. The semantic map stores stable coordinates: what "company" is, what "CEO" is, what "appointment" is. These coordinates change slowly. The graph stores specific appointments of specific people. These records change fast.
Structure and content. Slow and fast. Stable and transient. The boundary between them is exactly the boundary between Layer 1 and Layer 3. And the architecture must draw it not manually but automatically, through different update speeds.
What happens when the graph contradicts the map
Let us return to the question with which the second article ended. The semantic layer says: X is part of Y. Graph memory contains: X is not part of Y. What wins?
Now we can answer more concretely.
The semantic map does not store facts. It stores the type of relation. "Is part of" is a coordinate. The concrete statement "X is part of Y" is a record in the graph. If the graph says that X is no longer part of Y, this does not contradict the map. The map still knows what "part" is and what "whole" is. The concrete fact changed, not the structure.
A real contradiction arises when the graph contains a record that violates an invariant set by the map. For example, the map contains the pole "an organization cannot be its own founder", and the graph contains a loop: X → founder → X. This is not just a contradictory fact. This is a violation of a structural constraint.
In that case Layer 3 cannot resolve the conflict on its own. It escalates. And that is correct. Because resolving structural contradictions is not the task of memory. It is the task of whoever defines the rules.
Three layers as three modes of time
If we put everything together, a curious picture emerges. The three layers work on different time scales.
Layer 1 changes extremely slowly. Semantic poles are coordinates formed during training that then retain stability. They can adapt, but they do not react to every request. This is the geological time of the system.
Layer 2 lives on the scale of the current context. Every request unfolds a new local space, processes it and passes it on. This is the time of conversation, session time.
Layer 3 occupies an intermediate position. It changes faster than Layer 1 but slower than Layer 2. Facts are added, updated, become stale. But the structure of the graph, its ontology, its integrity rules are relatively stable.
Three modes of time. Three types of change. Three different update mechanisms. And three different answers to the question: "what to do when something changes?"
On Layer 1: almost nothing. Coordinates are preserved.
On Layer 2: anew every time. Context is formed for the request.
On Layer 3: pointwise. A specific connection is updated, the rest is left alone.
This is not just an engineering separation. It reflects how any knowledge is organized. There is what changes once in a generation. There is what changes every day. And there is what changes right now, at the moment of conversation. A system that tries to store all of this in one mode inevitably confuses the speeds.
What we proved and what we did not prove
At this point it is worth stopping and being honest.
We did not prove that graph memory works better than parametric memory for all tasks. For some tasks, a distributed representation inside the weights may be more effective — especially when facts are tightly interwoven and have no clear structure.
We did not prove that metadata (source, time, trust) can be automatically extracted and kept up to date. That is a separate hard problem, and it is not solved by one architectural scheme.
We did not prove that the escalation system for contradictions will not lead to constant false alarms. If the graph contains thousands of small inconsistencies, the system may escalate at every step, becoming practically useless.
We did not prove that splitting into a foundation and a change buffer will not create delays unacceptable for interactive tasks.
All of this is experimental questions. Each of them requires a benchmark, a baseline and a failure criterion. The architecture proposes a direction. The experiment will show whether it is the right one.
But we did something else. We turned the vague question "how should a machine remember?" into a set of concrete engineering tasks. How to store. How to edit. How to traverse. How to resolve contradictions. How to manage time. How to separate structure from content.
This is no longer a philosophy of memory. It is a specification.
What lies beyond the architecture
The three articles of this series traveled one path.
The first posed the question: where does meaning live if the model works with a sequence of tokens? And proposed an answer: perhaps meaning needs a separate layer of stable coordinates.
The second examined how these coordinates can emerge, learn, survive and not turn into decoration. And showed that every answer gives birth to a new problem: discrete choice breaks the gradient, dead poles empty the map, stream separation creates conflicts at the boundary.
The third showed that coordinates are not knowledge. Knowledge lives in the graph, and the graph must be able to store not only facts but also the attitude to facts: time, source, trust, contradiction. And that the problem of contradictory knowledge ultimately turns into a problem of time — the question of when a fact was true, where it came from and until what moment it remains relevant.
But behind all these layers there remains a question that no architecture closes.
Who decides which coordinates are correct? Who determines what is an acceptable constraint and what is censorship? Who bears responsibility when the system escalates and a human makes a wrong decision? Who updates the graph when the world changes faster than the system can record it?
The architecture can make these questions visible. It can create a place where they are formulated. It can divide responsibility between layers so that no layer makes decisions that a human should make.
But it cannot answer them on behalf of the human.
And perhaps this is the main property of the whole construction. Not that it solves the problem of meaning. But that it does not let the system solve it for us.
Instead of a conclusion
When we started, the question sounded like this: where does meaning live?
Now we can answer a little more precisely. Meaning does not live in one place. It is distributed across three modes.
Stable coordinates — in Layer 1. They change slowly and set the frame of reference.
Living context — in Layer 2. It is formed anew every time and does not claim eternity.
Changeable knowledge — in Layer 3. It stores facts, their sources, their time and their contradictions.
None of these layers is "understanding". But together they create a structure in which understanding can be not just a probabilistic pattern but an explicit, verifiable and editable object.
Or it cannot. The experiment will show.
But even if the architecture is not confirmed in its stated form, the question itself remains. Because as models grow larger, contexts longer and tasks harder, the question "where does meaning live and who controls it" will keep arising. Not as a philosophical abstraction. As an engineering task.
And then answers will be required. Not to the question "does the machine understand". But to the question: what structure does it build, who can change it, and what happens when it is wrong.
This is no longer a question about the machine.
It is a question about what form we want to preserve for ourselves.