Chapter 24
What Time Exists in Memory
Chapter 6 announced three axes of time, Chapter 10 said they are storage, and Chapter 18 used them first as a search filter. This chapter looks at how the three axes actually work.
1. Three axes
When the thing a record speaks of happened, when the record entered the graph, and until when the record's claim holds are three different questions.
| Axis | Question | Where it lives |
|---|---|---|
| content time | When did the thing the memory points at happen? | Concepts, Records, documents |
| graph time | When did the graph create, change or learn this? | creation and update stamps, revision, sync sequence |
| valid time | Over what interval does this claim hold, as a claim? | a Record's start and end; on a Decision, its properties |
New is not current. A Record written today about 2025 is new in the graph and historical in validity. A Decision from January is old in the graph and current until its end arrives.
2. Mixing the two clocks produces errors
Suppose something happened on 20 August and was recorded on 1 September. The event's content time is 20 August; the graph time of the Record that wrote it down is 1 September.
A recently created Record does not mean the event happened on 1 September. An old event's Record being edited recently does not mean the event happened again. Neither clock stands in for the other.
3. The validity window, and how to read what is not written
For information that was true once and may not be now, a price or a policy, the time of the event and the window of the claim have to be kept apart.
Record content_time when it happened valid_from from when the claim holds valid_until from when it no longer does
The window is half-open: it holds at the start and not at the end.
And a claim with no window stated is read as current. That sentence is load-bearing rather than tidy. On the day the policy was adopted, 38 percent of the hub's Records carried no start, because most of them assert nothing about a present state. A default that hid every unstated claim would have hidden the present, not the stale. Only one thing hides a claim: an explicit end. By that evening a start was set on 747 of 748 Records, and the rule stays binding anyway. The next unstated write is one call away.
4. Currency is computed, never stored
Whether a claim is current, historical or not yet in force follows from the window and the clock. It is computed at read time and written nowhere. With no start or a start passed, and no end or an end still ahead, it is current; with the end passed, historical; with the start still ahead, not yet in force.
A stored status repeats what the fields already say and drifts from them the moment either moves. So there is no status = stale anywhere.
Historical is not false. A Record whose end has passed is still a true account of what held then. Invalidation means the claim is no longer the operative one, not that it was wrong.
5. Which kinds carry a window
Forcing the same time fields onto every Node is not the right design. It differs by kind.
A Record that asserts a present state requires a start, and takes an end when it is superseded or retired. A Record that preserves a past measurement needs only its content time and may read as historical.
A Decision is a judgment inside the system, not an outside event, so it has no content time; its graph time says when it was made. But a Decision that sets a policy, “we encode with this model”, “one replica”, can be replaced by a later one, and then it needs a window as much as a Record does. So operational and policy Decisions carry a window, and design decisions and one-time judgments do not. Classified on 11 September 2026, 71 of the 177 live Decisions carry one and 106 do not. The Decision table has no columns for it yet, so the window rides in the properties. That is an encoding, not the design.
A definitional Concept needs no window. An Episode is an event on the timeline with a date of its own, and its order is the point.
6. Supersession
When a new claim replaces an old one at time T, the old claim's end is set to T, the new claim's start to T, and the old one points at the new. Both remain. A timeline shows the succession without deleting anything.
For material that carries authority, supersession is required, not optional, and the reason was measured on a document about this very subject. A measurement report was true in the early morning and false in four places by mid-morning, overtaken by the work it described. No end time could have caught it: nobody knew at dawn that the claims would be replaced, and a window needs an author who already knows the end. What that document needed was a successor pointing back at it.
The write path cannot yet store succession as a relation. No such relation type exists, and in Chapter 11's table a Record can never connect to a Record. So the successor rides in the properties, and the read path returns it with the node and says so when the node is not current. Seven Records and two Decisions are superseded this way today.
7. What the read path does, and does not yet do
Search and brief look, on both node arms, at current claims only by default, read unstated as current, and return historical claims only on request. As Chapter 18 said, that filter must change what is visible and never what the answer is, and that rule was learned from one accident.
Two things it does not yet do. Document chunks carry no validity, so a retired plan is found as readily as a live one. And the desktop app draws no interval on any card. Both are written down as open rather than hidden.
8. Rigor inside, lightness outside
The three axes must not make Vinc harder to use. A person writes what they know. Nobody is asked to enter a start, an end, current or historical, or a successor on every node. The system infers from language, from surrounding evidence and from explicit dates, and asks for confirmation only when the distinction actually affects correctness.
Three levels are the right shape. In ordinary writing the time fields are mostly invisible. When needed, a person can inspect and correct temporal meaning: when did this claim start to hold, what did it replace. Search, brief and Agents use the three axes to put current claims first, keep historical ones on request, and follow chains of supersession. The graph model being rigorous is no reason to move that rigor onto the customer.
9. Time shows in two ways
Two things sitting in time order does not make one the cause of the other. “A came before B” and “A is a precondition of B” are different claims, and the second is said not by this chapter's clocks but by the relations of Chapter 11. That relation is Chapter 27.
And time appears on screen in two ways. The Timeline viewpoint arranges memory along recorded time or content time. Whether you are looking at the state that holds now or the state that held then is not a question of the camera but of the state of the information. That distinction is the first rule of the next chapter: where you are looking and how you are looking are different axes.
Continue with Chapter 25, How Nodes and Edges Become Visible.