TL;DR
- 01Every node and every edge in the kernel carries two clocks: valid-time (when it was true in the world) and transaction-time (when the system learned).
- 02Most software collapses them. Conflict work needs both, separately. A commitment made Monday and learned Thursday has a Monday valid-time-start and a Thursday transaction-time-start.
- 03The kernel makes this discipline non-optional. The validator rejects admit-without-times.
- 04As-of, drift, and retrospective queries are first-class.
Every node and edge in the kernel carries two clocks: when something was true in the world and when the system learned about it. Most software collapses them. Conflict work needs both, separately.
Two clocks, separately
Valid-time records when an asserted fact holds (or held) in the world. Transaction-time records when the system recorded the fact. Both are intervals, not points; both can be open-ended; both are queryable independently.
Invalidation is non-destructive: a contradicting edge sets the prior edge's t_tx_end to now, and the new edge inserts with its own t_tx_start. Both remain queryable. Queries scoped to t_tx ≤ T return the state of knowledge at time T.
Query semantics
- ▸
query @ t_tx = T→ what the system knew at T. - ▸
query @ t_valid = T→ what was true at T in the world, using current knowledge. - ▸
query @ (t_tx = T1, t_valid = T2)→ what the system at T1 believed about the world at T2 (retrospective). - ▸
query drift(target_id)→ the ordered sequence of valid-time intervals a node or edge occupied, including invalidations.
Why it matters
A policy reviewer or oversight body needs to be able to ask: what did the desk officer believe on Wednesday about the situation as of Tuesday? Generic AI tooling cannot answer this. The bi-temporal graph can.
SOURCES
