Bi-temporal modeling is table stakes for agent-era data platforms

Every time an agent acts on your data, it asks two questions at once: what is true right now, and what did this system believe when it made that decision? Most platforms can answer only the first, because they track a single timeline. Bitemporal modelling is what separates a platform that can answer both from one that quietly rewrites history — and that separation is now table stakes.

The mechanism is old and boring, which is the point. Bitemporal systems keep two independent time axes: business time, when a fact was true in the world, and system time, when the system recorded it. Four timestamp columns, two half-open intervals. The reason it matters for agents specifically is that agents are the first data consumer that learns late by default — a customer moves in March, the fact lands in August, and an agent that acts on what it reads must not silently overwrite the March record, nor hold two contradictory beliefs. The warehouse world already named both outcomes and their fixes: a late-arriving change splits an existing validity interval and re-stamps the neighbours, and it is the retroactive-change case, distinct from a correction, where the original entry was simply wrong. Both are append-only operations, and each leaves a different transaction-time footprint. For a system that spends money or touches customer records, that footprint is not ceremony — it is the difference between an auditor reconstructing a decision and a system that cannot say what it believed on Tuesday.

None of this is a research problem. The four-column schema is the consensus across every practitioner and academic source, SQL:2011 standardised it as system-versioned and application-time period tables, and the query semantics sit on top of Allen's thirteen interval relations. What the last fifteen years actually prove is that you cannot outsource this to the database and call it done — the vendor divergence is total. SQL Server implements system time only, no application time at all; Oracle leans on Flashback rather than native system-versioning; PostgreSQL still has no native system time. The one reliable conclusion from the survey: portable bitemporal design is a modelling decision you make in the platform, not a feature you inherit from the engine. Databricks has drawn the same line — AUTO CDC accepts STORED AS BITEMPORAL and generates the two system-time columns beside the business-time pair, a config flag rather than a project.

That is the strongest form of my argument: the substrate has caught up. What used to be a database-theory elective is now a clause in a declarative pipeline, available on the same lakehouse that already does time travel and ACID merge. Agent memory systems are converging on it from the other direction — Graphiti and Zep store both system time and valid time per fact precisely so they can answer "what did the user believe on Tuesday" against "what was true on Tuesday." The two ends of the stack are meeting in the middle, and the platform that has not modelled time as two axes is the one that will have to retrofit it the day its agent makes a decision someone asks it to justify.

The concession, precisely stated: bitemporal modelling is not universal, and most workloads genuinely do not need it. Append-only storage is expensive — full bitemporality can roughly quadruple row volume — and the Graphiti researchers themselves say most agent workloads get by without the distinction, reserving it for systems that must be auditable. If nothing your agent touches is regulated, contested, or expensive, single-axis time travel is fine. But that is a decision you are now expected to have made, and the burden is on the defender: agent-era platforms are auditable-by-default, and the systems that are not had better be able to say why, in writing, before the first correction arrives.