What TGMS Is — and Is Not

In one sentence: TGMS is a store for facts that change over time, built so an agent can ask what was true, ask what the system believed at some past moment, and get an answer whose supporting evidence can be checked — and it is not a general replacement for the database you already run.

Why this matters

Give a language model a question about a changing world and it has two bad options. It can be handed a pile of text and asked to reason over it, which works until the question needs counting, grouping, or following relationships several steps out. Or it can be handed today's database, which answers about now and quietly loses the fact that last month's answer was different — and that someone corrected the data on Tuesday.

Two problems live in that gap:

• Structured temporal computation. "How many distinct accounts did each region message in March?" is arithmetic over relationships in a time window. A model that estimates it is guessing; the computation should be executed, not narrated.
• Auditable answers. When the answer matters, "the model said so" is not a citation. You need to know which records produced the number, and whether the records were complete.

The idea in plain language

TGMS has three parts. The vocabulary here is used by every other post in this series.

1. A bi-temporal store. Every fact carries two clocks: when it was true in the world, and when the database believed it. Recording a correction appends a new version rather than overwriting the old one, so the question "what did we believe on 1 April?" stays answerable after the data is fixed on 10 April. That second clock — what the system believed, and when — is what bi-temporal adds, and reconstructing an answer at a past moment gives you a past belief state.

2. Verified operations. Questions are not answered by free-form code. They are answered by 15 named verified data operations — filter a time window, follow relationships forward in time, group and count, find a repeating pattern — each with a checked input and output contract, each with an independent reference implementation that tests agree with it. Several of them chained together is a plan.

3. A plan–execute–verify loop. The model writes the plan; the engine executes it; a verifier then checks that every claim in the final answer is actually supported by what the operations returned. A claim computed over a result page that was cut short is marked rather than believed — the value can be arithmetically correct and the evidence still incomplete.

One question, all the way through

Take a real shape: "In March, how many distinct accounts did users in each region message — as we believed things on 1 April?" A correction landed on 10 April moving several accounts to a different region.

1. The store holds every relationship version with both clocks, so "as believed on 1 April" is a filter over data that is already there. Nothing is rebuilt or restored, and the 10 April correction is simply not yet visible at that belief time.
2. The operations do the work: select the March valid-time window, group by region, count distinct recipients. Each is a named operation with a contract, so the plan is checkable before it runs — and the result carries a fingerprint, which is how we verify that five other systems answering the same question get byte-identical results.
3. The verifier checks the final claim against what came back. If the result had been truncated by a row limit, the distinct count would rest on partial evidence, and the claim is marked instead of asserted.

The same question asked today, without the belief filter, gives a different and equally correct answer. Both remain available, permanently. That is the whole point.

What TGMS is not

It is not a general replacement for the database you already run, and the measured boundaries are specific.

• Not a replacement for PostgreSQL. If your workload is transactional writes, high-rate indexed reads over current state, or anything wanting a mature general query optimiser, PostgreSQL is the better tool. On point lookups the two are close and the ordering depends on scale — 0.1 ms against PostgreSQL's 0.3 at 200k events, with PostgreSQL ahead again at 10M.
• Not a replacement for ClickHouse. Large whole-window aggregation is a column store's home ground, and above a few hundred thousand events it holds a steady factor of two: at 10M events ClickHouse answers the bucketed count in 37.9 ms against our 84.7, a factor of 2.2 — the same ratio at a million, and a tie at 200k. If nightly rollups over tens of millions of events are the job, use a column store; our own numbers say so.
• Not a replacement for Neo4j or a general graph database. TGMS is faster on bi-temporal traversal by about two orders of magnitude — 14.7 ms against 3.9-7.3 seconds at 200k events — because every hop re-filters by validity and belief, which no index in those engines accelerates. That is a statement about temporal workloads, not about graph engines in general. For ordinary non-temporal traversal we have no evidence, and for arbitrary subgraph pattern matching a general graph database is strictly more expressive than our fixed catalogue of five shapes.

A realistic deployment is often TGMS beside one of these: the temporal-graph composition here, the rollups there.

Maturity, plainly

TGMS is a research system at version 0.5.0. The limits that will affect you first:

• Single writer. One writing process at a time; concurrency is read-side only until belief-state isolation exists.
• Fixed pattern catalogue. Five motif shapes, not arbitrary pattern matching.
• Name resolution is current-canonical and string-only. Matching runs over the latest believed name; looking an entity up by a historical alias is not offered — a real gap in a system otherwise built around history.
• Coverage. Of 110 questions written by people who had never seen the operator list, 83 are expressible in the current operation set. That number is the honest measure of how much of a real analyst's curiosity this system can serve today, and it is the one we most want to move.

What this page does not establish

• The comparisons are one host, one synthetic workload family plus one frozen real dataset, warm caches, single client. They do not cover OLTP, distributed operation, or cold start.
• Answer-quality figures elsewhere in this series come from specific models on specific task sets — for example 41% normalized typed-answer accuracy — the share of answers matching the reference, counts and values exact and interval answers credited at IoU ≥ 0.5 (pooled, Qwen2.5-14B). They are not claims about language models in general.
• Where this series reports that a campaign produced 0 unsupported claims, that is among the 199 answers it emitted across 282 task runs — a result on a task set, and part of the zero is bought by declining to answer the other 83.

Takeaway

TGMS is narrow on purpose: it makes questions that combine history, correction and relationship structure computable and checkable, and it is second-best or worse at nearly everything else. The useful question is not whether it is faster than your database, but whether your questions have that shape.

Where to go next

• If you want the idea: why an agent needs two kinds of time, then why valid plans still fail and why a verifier must check evidence, not just arithmetic.
• If you are evaluating it: where TGMS is fast and where specialists still win, then why the storage engine exists and what remembering costs.
• If you like watching measurements overturn beliefs: racing the specialist and how a resident index slowed an unrelated scan by 18%.