← TGMSblog github
Post #1 · Understand TGMS

Why TGMS stores
two kinds of time

One clock records when something was true; the other preserves what the system believed before a correction.

Xiaofei Zhang · University of Memphis · paper · code
First published July 2026 · TGMS 0.4.0 · snapshot matrix-dev-oss-14b · 7 min read · Status: Current

In one sentence

A database that can be corrected needs to remember two different things — when a fact was true in the world, and when the database believed it — because otherwise a correction quietly destroys the only record of what anyone acted on.

Why this matters

Start with a question an auditor actually asks:

“As of 1 March — before we corrected the record — what did we believe about this account?”

It sounds niche. It is the ordinary shape of after-the-fact review. A trade is queried months later and the reviewer needs the position as the desk understood it that morning, not as it reads today. A moderation decision is appealed, and what matters is the evidence the reviewer had, not what arrived afterwards.

Now notice that two very different events both arrive at a database as “change this row”, and that only one of them is about the world.

The world changed “The collaboration ended in June.” The old record was correct while it lasted. Nothing was ever wrong. active ──▸ ended The record was corrected “It never included Bob. Fix it.” The old record was never right — but it was believed, and acted on. wrong all along, believed anyway
The distinction the rest of this post rests on. Both events look like an update; only the top one is news about the world. Overwriting is a faithful response to the first and destroys evidence in the second. This is a statement about what a record must retain, not yet about how any system stores it.

If your data layer is a snapshot, a vector index, or a plain property graph, the second row is where information goes missing. The old value is gone, so a question about what was believed on 1 March has nothing left to read. That is not a hard query — the input it needs was discarded at write time.

The idea in plain language

The repair is old, and comes from temporal databases: keep two clocks instead of one.

The first is easy — record the stretch of real-world time over which a fact held. A collaboration that ran from January to June is stored with that interval, so “ended in June” is a new interval rather than a lost one. This clock is valid time.

The second clock is the one that survives corrections. Alongside every version, record the stretch of time during which the database held that version. When a correction arrives, the old version is not overwritten; it is closed on this second clock and a new one opened. Ask about today and you get today's answer. Ask about 1 March and you get the answer the system would have given on 1 March — including the part that later turned out to be wrong. This clock is transaction time, and the state it lets you recover is a past belief state.

None of this is our invention, and pretending otherwise would be both wrong and strategically foolish. Two-clock records have been studied since the 1980s — Richard Snodgrass's temporal-database work is the standard starting point — the SQL:2011 standard added bi-temporal tables to SQL itself, and production systems exist whose whole identity is bi-temporality: XTDB is the one we measure against, and its SQL dialect implements exactly the two clocks described above. What TGMS adds sits on top of that inheritance: a graph data model over both clocks, a physical design that makes correction-aware graph queries cheap, and an operator surface an AI agent can be handed without being able to fabricate history. The evidence that we and XTDB mean the same thing by these words is in the head-to-head: four hundred belief probes, zero disagreements.

valid time → Jan Mar Apr Jun belief before owner = Ada · all of Jan–Jun correction: “in March it was Bo” belief after Ada Bo Ada The top row never stops being readable — asking for the March belief still returns it, unchanged.
A correction carves out the interval it disputes and leaves the rest of the old version standing, rather than replacing it. Both rows remain readable, each under the belief time you ask for. The figure shows the storage shape only; it says nothing about which of the two owners is substantively right.

How TGMS handles it

The point of the design is that recovering a past belief is a parameter, not a reconstruction. Every data operation in TGMS accepts an as-of belief time, and the store applies it as a filter while reading. The language model's job is to choose the right operation and arguments; it never re-derives history, and it never sees the versions the filter excluded.

question “as of 1 March…” model selects operation + as-of time TGMS filters by belief time versions believed that day The model chooses which question to ask. The store decides what was believed.
Time travel is a filter applied by the store, not an inference performed by the model — so the answer is deterministic and repeatable at any model size. The boundary this draws is about retrieval: choosing the right operation and belief time is still the model's job, and that is where it can still be wrong.

In practice that is one argument:

# What did we believe on 1 March, before the correction landed?
entity_history(uid="n605", as_of_tt=BEFORE_CORRECTION)
  → 1 version   # the record as it stood that morning

# And what do we believe now?
entity_history(uid="n605", as_of_tt=CURRENT)
  → 3 versions  # before · corrected · after
Sidebar · the test that keeps this honest The property is easy to state and easy to break: a result pinned to a past belief time must be byte-identical before and after any later correction. TGMS pins it with a metamorphic test — run a query, apply a correction, run the same pinned query again, compare fingerprints. Making it pass exposed two real leaks: result fingerprints that mixed in current-belief metadata, and version rows whose closing timestamps revealed that a correction had happened later. Both were invisible to ordinary tests, because ordinary tests only ask whether today's answer is right.

What we measured

Evidence box
Question
Can systems without a belief-history record answer questions about a past belief?
Workload
22 development tasks over a message-log dataset, of which 3 are correction probes — the same question asked once before a correction and once after, with gold answers that provably differ. Corrections are injected before any gold answer is computed.
Compared
TGMS; vector-RAG over serialised events; static-graph RAG over the latest snapshot; text-to-Cypher over the same events in a plain property graph.
Metric
Answer accuracy (normalised typed-answer accuracy: exact for counts and values, interval overlap ≥ 0.5 for intervals). Higher is better.
Held constant
Same model (Qwen2.5-14B-Instruct-AWQ, single 24 GB GPU), temperature 0, same seeds, same typed answer format, same repair budget.
Run
Single deterministic run per system; the probe row is 3 tasks, so treat it as a demonstration of representability rather than a rate.

What we found

Across all task families TGMS leads, which is the unsurprising half: computing over structure beats retrieving text when a question composes time. The interesting half is the probe row. Every baseline scores zero — not a low score, zero — while TGMS answers two of the three.

ALL 22 DEV TASKS — answer accuracy, higher is better TGMStext-to-Cypher vector-RAGstatic-graph RAG 41% 18% 9% 5% THE 3 CORRECTION PROBES TGMSall three baselines 67% (2 of 3) 0% — the belief history is not in their input
Qwen2.5-14B, temperature 0, single run, snapshot matrix-dev-oss-14b. The zero is a representability result, not a difficulty result: the baselines' inputs no longer contain the superseded version, so no amount of reasoning recovers it. Red marks that missing capability, not a slow system. The probe row is 3 tasks — enough to show the gap exists, far too few to size it.

What this means in practice

The rule generalises past graphs: any store that can be corrected and is then asked about the past must record its own belief history, or its answers about the past will silently reflect today's beliefs. The same reasoning applies to derived data — a cached summary computed last month is a claim about last month's beliefs, and a correction touching its window invalidates it.

Good fit when corrections are routine and someone later asks what was known at the time — audit trails, regulated records, moderation review, feature stores, revised scientific datasets. Consider another approach when the record is append-only and never corrected: then valid time alone is enough, and the second clock is storage and complexity you will not use.

What this result does not show

This design preserves belief history; it does not adjudicate which version is true. TGMS can tell you that on 1 March the record said Ada and that it now says Bo. It has no view on whether the correction was itself correct — a mistaken correction is stored with exactly the same fidelity as a well-founded one. Deciding which version reflects reality remains a human and organisational question, and nothing here should be read as automating it.

Two narrower boundaries. The probe comparison is 3 tasks on one dataset at one model size; it establishes that the baselines cannot express the question, not how often TGMS gets it right. And the baseline zeros belong to this development split — on the larger frozen split, vector-RAG scores above zero on probes, which on inspection comes from the current-belief half of each probe pair rather than from any recovered history.

Takeaway

One clock is not enough for a record that can be corrected. Store when a fact was true and, separately, when you believed it, and “what did we think on 1 March?” stops being an archaeology project and becomes a filter the database applies for you.

Evidence and reproduction

Method, baselines and the full result tables are in the paper (§6). The metamorphic property is pinned by tests/test_metamorphic.py; the belief-time filter and the two leaks it caught are in tgms/temporal/ops_snapshot.py and algebra.py. Every number on this page is quoted from docs/site_facts.json and checked in CI. A rendered end-to-end trace with per-claim verification badges is here.

Continue reading

Prerequisite: none — this is the start of the series. If you want the one-page version of what TGMS is first, the project page has it.