theme-bitemporal-supersession explains why nothing is ever overwritten. This page traces one real fact through the model so the mechanism is visible rather than asserted — not a hypothetical example, the actual Decision I → Decision U reversal from 02-architecture-decisions, which happened twice in one day.
What actually happened
On 29 June 2026, the design register first settled on retaining every superseded entity’s embedding forever, specifically so a future historical-search feature would never need to re-embed anything. Later the same day, that was struck and replaced: evict the vector on supersede, keep the underlying assertion text permanently, and re-embed on demand later (Path 2) rather than carrying every historical vector forward. Neither version was deleted when the second was written — that’s the whole point of the model.
flowchart TB Q1["Query: what's true now?"] --> CUR[("Current-pointer cache<br/>rebuilt from the log")] Q2["Query: what did we believe<br/>at midday on 29 Jun?"] --> V1 CUR --> V2 subgraph LOG["Append-only log"] V1["v1 · 29 Jun, morning<br/>keep every old embedding"] V2["v2 · 29 Jun, afternoon<br/>evict old vectors, keep text"] V1 -->|superseded by| V2 end
Why both queries are correct
Ask “what’s true now” and the current-pointer cache — a derived index kept in sync with the log, never the source of truth itself — hands back v2 straight away, no replay needed. Ask “what did we believe at midday on the 29th” and the answer is genuinely v1, not an error and not a stale record — at that instant, v1 was the only assertion that existed. A flat, overwrite-in-place store can only ever answer the first question; the moment v2 was written, v1 would simply be gone, and “what did we believe then” would have no honest answer left to give.
The distinction this relies on — valid time (when a fact was true in the world) versus transaction time (when the store found out about it) — is exactly the axis theme-bitemporal-supersession describes the earlier, rejected design as collapsing into one. Here, both versions of Decision I share almost the same valid time (both describe “the design, as of 29 June”) but have different transaction times (morning vs. afternoon) — which is precisely why they need to be two rows, not one row edited in place.
Sources: 02-architecture-decisions (Decision I struck and superseded by Decision U, same day, 29 Jun 2026); theme-bitemporal-supersession (the valid-time/transaction-time distinction this example turns on).