TGMS design notes

One design choice at a time: the problem it solves, how the system handles it, what we measured, and what the result does and does not show. Start with the two-clock model, or browse by architecture, evidence and engine design.

Start here

New to the project? These read in order — each one assumes only the ones before it.

  1. What TGMS is — and is not · five-minute orientation
  2. Why TGMS stores two kinds of time · the problem it exists for
  3. Why AI tools need output contracts · how plans are kept valid
  4. A correct number can still be unsupported · how answers are verified
  5. Why TGMS needed a native storage engine · the storage rationale
  6. Where TGMS is fast — and where specialists win · workload fit
  7. The bi-temporal competitor agrees · the head-to-head with XTDB
All posts · newest first
#11 Evidence & capability

The bi-temporal competitor agrees — and that is the headline

How do we know TGMS’s two clocks mean the same thing everyone else means by bi-temporality?

Bi-temporality is inherited — SQL:2011, decades of temporal-database research, XTDB in production — not invented here. One op stream replayed into both systems: 400 belief probes, 0 disagreements, and TGMS 3.9–4.7× faster at correction-heavy ingest on 23–27× less disk.

#10 Engineering case study

How a resident index slowed an unrelated scan by 18%

A published number stopped reproducing. What broke — the code, the machine, or the measurement?

The obvious hypothesis measured false, a 5-build bisect landed on a commit touching no scan path, and a four-condition probe found an index costing 18% just by being resident — including in our own benchmark table.

#9 Engineering case study

Racing the specialist

What happens when you build the operation you are worst at and race the system that is best at it?

We wrote the SQL and Cypher baselines before writing the feature, lost to ClickHouse above a few hundred thousand events, and found the gap was one aggregate — after our first explanation of it turned out to be wrong.

#8 Evidence & capability

The operational cost of keeping a correctable history

What do you actually pay to keep a history you can correct?

No measurable overhead when nothing is corrected; storage and latency that grow with correction density; a per-process warm-up of about half a minute; and a memory floor that kills rather than slows. Four deployment profiles, and what the numbers do not cover.

#7 Evidence & capability

Where TGMS is fast — and where specialists still win

Which system should answer which shape of query?

13 queries on 6 systems, every cell hash-verified before it was timed: TGMS owns the shapes combining history with graph structure, ClickHouse owns large-scale aggregation, and building the baselines honestly fixed two defects in our own engine.

#6 Understand TGMS

Why TGMS needed a native storage engine

Why write a storage engine instead of using one that exists?

Four properties had to hold at once and no adoptable backend delivered the conjunction. On immutable segments plus append-only corrections, 25.1 bytes per relationship version, and a fast path that never once ran.

#5 Evidence & capability

We let users define the workload

What do people ask a temporal graph store, when nobody shows them the manual?

10 of 110 independently written questions were expressible; after building the capability the study ranked first, 24 are. The gap between 30 predicted and 14 delivered is the useful part.

#4 Evidence & capability

Bigger models help only when the data interface can use them

Does a stronger model make a temporal system better, or is the interface the limit?

Changing only the model, answer accuracy rose from 13.8% at 7B to 62.8% at 32B through an operator interface, and from 9.6% to 27.7% through the strongest retrieval baseline. The 72B point varies precision as well as size, so it is reported detached rather than as the end of the curve.

#3 Understand TGMS

A correct number can still be unsupported

If the arithmetic is right and the citation checks out, can the answer still be wrong?

Yes — it counted 100 rows of a 343-row result. Completeness has to travel with the evidence, or a verifier will bless a confident summary of half the data.

#2 Understand TGMS

Why AI tools need output contracts

Your tool's input schema is airtight — so why did a model still break every plan?

Nothing constrained the field names it read back out of your results. Declaring output fields took execution success on the probe tasks from none to all of them.

#1 Understand TGMS

Why TGMS stores two kinds of time

What happens to the record of what you believed, when a database corrects itself?

Storing when a fact was true separately from when the system believed it turns “what did we think on 1 March?” into a filter the database applies, not an archaeology project.

#0 Understand TGMS

What TGMS is — and is not

What problem does an agent-native temporal store actually solve, and what should you keep using PostgreSQL for?

A five-minute orientation: the three components, one question carried end to end, and a plain statement of the workloads other systems still do better, each cited to a measured shape.