What Is a Bi-Temporal Knowledge Graph? (and Why AI Memory Needs One)

TL;DR

• A bi-temporal knowledge graph tracks every fact on two clocks instead of one.
• Those clocks are valid time (when a fact was true in the world) and transaction time (when the system learned it).
• One timestamp can't answer both "what is true now" and "what did we believe in March."
• Old facts get invalidated, not deleted, so the full record stays auditable.
• For AI agents, that structure is what stops a model from restating deprecated facts as current.

What "Bi-Temporal" Actually Means

A bi-temporal data model tracks two independent kinds of time for every fact it stores. Valid time is the period during which a fact is true in the real world. Transaction time is when the system actually recorded that fact. The terms come from Richard Snodgrass and are codified in the SQL:2011 standard. Martin Fowler finds those labels confusing and prefers the plainer pair of actual time and record time, which name the same two axes.

A database that tracks only one of these axes is uni-temporal. Most systems are. They store either when a fact is true or when they learned it, never both, and the missing axis is where the trouble starts.

A valid-time-only store knows your pricing changed on March 1, but it cannot tell you what the system believed about that price on February 25 when someone made a decision. A transaction-time-only store knows when each record landed, but it cannot represent a backdated correction without overwriting what came before. Either way, you lose the ability to separate what was true from what you thought was true. A bi-temporal model keeps both axes side by side, so every fact carries an answer to two different questions at once.

The Two Time Axes, Illustrated

Picture a SaaS company that raises its Pro plan from $40 to $50 per seat. The finance team logs the change on March 15, but the price was contractually effective March 1. Two weeks of invoices already went out at the old rate. Now an agent gets asked, "What was the Pro price on March 5?" There are three honest answers, and only one of them is the right one to act on.

A valid-time-only view returns $50, because that was the contractually true price on March 5. A transaction-time-only view returns $40, because that is what the billing system actually knew and charged on March 5. Both are correct about different questions. A bi-temporal system keeps both and lets you ask either one. It can tell you the true price on March 5 and separately tell you what the system believed on March 5, which is what reconciles the invoices.

Holding both answers at once forces four timestamps onto every fact, not one. The pair validStart and validEnd marks the window during which a fact was true in the world. The pair transactionStart and transactionEnd marks the window during which the system believed it. The $40 record carries a valid interval that the March 15 correction later contradicts, yet its transaction interval stays intact as proof of what billing ran on. Open-ended facts use a sentinel end date like 9999-12-31 until something supersedes them.

Martin Fowler's payroll example makes the same point with Sally's salary, and the four-timestamp structure falls out of it for the same reason. You cannot answer both "what was true" and "what did we know" with a single date.

Why One Timestamp Is Not Enough

A single timestamp forces a system to throw away one of two answers it will eventually need. Store only valid time, and you can say what was true in the world on a given date, but you lose any record of what the system actually believed when it made a decision. A March audit that asks "why did the agent quote the old price?" hits a wall, because the corrected price has overwritten the figure the agent saw.

Store only transaction time, and the opposite failure appears. A fact corrected after the event silently rewrites history, so a backdated salary change or a retroactive policy update erases the version the system once recorded. You can see when a record landed, but not the period the fact was actually true in the world.

For an AI agent, that gap becomes a behavior problem rather than a reporting inconvenience. An agent reads facts and acts on them, so a memory layer that cannot separate "true now" from "believed then" hands the agent no signal that a fact has been superseded. The agent restates a deprecated price, an old org chart, or a retired policy as current fact, with full confidence. Sentra treats both axes as first-class, marking when a fact became true and when it stopped, so an agent never repeats a stale answer as the present state.

Invalidate, Don't Delete

A bi-temporal system corrects facts by appending new records, never by erasing old ones. When a fact changes, the system closes the transactionEnd interval on the existing record and writes a new one. The original row stays in place, marked as what the system believed during the period it believed it. That single rule is what lets you ask both "what is true now" and "what did we think was true in March" and get a correct answer to each.

The two time axes behave differently here, and the asymmetry matters. Valid time can be corrected retroactively, because the world's truth about a fact can turn out to have been different than recorded. Record history cannot be rewritten, only extended. As Martin Fowler puts it, "we don't change what we thought we knew. We just append the later knowledge we gained" (martinfowler.com).

Sentra applies the same principle to its context graph. Old facts are invalidated, not deleted, and provenance stays first-class, so an agent can reconstruct exactly what the organization knew at any past decision point.

Single-Temporal vs. Bi-Temporal: A Quick Comparison

The difference between single-temporal and bi-temporal storage comes down to four design choices, and each one decides whether an AI agent answers with current facts or stale ones. The table below maps those choices against the consequence that matters most.

The single-temporal column describes most flat vector stores and conventional databases, where a correction destroys the record of what the system once believed. The bi-temporal column describes Sentra's context graph, where every fact carries a valid-time interval and a stop-time, and old facts are invalidated rather than removed. That distinction is why an agent built on a bi-temporal layer can answer "what is our policy now" and "what did we think in March" without contradiction.

Why AI Memory Specifically Needs This

The cost of conflating "true now" with "true then" rises sharply once an autonomous agent reads the memory. A human who pulls a stale pricing doc usually catches the error through context or a quick check. An agent treats whatever it retrieves as a fact and acts on it, quoting a deprecated price to a customer or executing a workflow against a policy that was rescinded last quarter. The reader is no longer a person who can second-guess the answer. It is a system that runs on it.

Flat vector stores make this worse because they embed meaning at write time and weight old and new facts equally. When an agent queries a vector store, it gets back what is semantically close to its question, not what is currently correct. A 2023 pricing memo and a 2025 update sit at similar distances from the query "what do we charge for the enterprise tier," and the store offers no signal that one superseded the other. Vector search returns what is close, not what is correct.

A bi-temporal structure gives a memory layer two independent levers, and that separation is what fixes the failure. You can correct what was true in the world (valid time) without erasing what the system once believed (transaction time). An agent answering "what is our price today" reads the current valid record. An auditor asking "what did we tell that customer in March" reads the transaction history as it stood then. No single-axis design supports both questions at once, because each axis answers a question the other cannot. Auditable history and correct present-state answers are not competing goals here. They are two reads of the same graph.

How Sentra Implements Bi-Temporal Memory

Sentra builds the principles above into a working memory layer that sits beneath your agents, not beside them. The design choice that defines it is write-time comprehension. Sentra resolves what a fact means at the moment it arrives, against a per-organization ontology, rather than rediscovering meaning on every query. Vector-based RAG works the other way around. It stores embeddings at write time, then guesses structure when an agent queries, so every request crawls Slack, email, and docs to figure out what something means again.

That difference changes how time gets handled. When a new fact contradicts an old one, Sentra invalidates the old fact instead of deleting it. Each fact carries both a valid time and a stop time, so an agent can ask what is true now and what was true in March and get two different, correct answers. Provenance stays first-class, which means the system can always show where a fact came from and when it changed.

The benchmark numbers measure whether that design actually holds. On the MEME benchmark (KAIST, 2026), Sentra scores 40% on Cascade and 43% on Absence, against field averages of 3% and 1%. Those two tasks test exactly the behavior bi-temporal structure exists to support, tracking how a fact propagates after it changes and recognizing when something is no longer true. Sentra is the only system above 30% on both.

The shared-layer claim rests on reach, not just structure. Sentra connects to 200+ tools through REST or MCP, including HubSpot, Gmail, Slack, GitHub, Notion, and Linear. One graph reads from all of them and serves humans and every agent from the same source, so a correction made once propagates everywhere instead of living inside one model's session.

FAQ

Is bi-temporal the same as event sourcing?

Event sourcing stores every change as an immutable event, while bi-temporal modeling tracks two distinct time axes on each fact. The two work together. Many bi-temporal systems use an event log to record changes, with each event carrying both a valid date and a record date. You can build bi-temporal storage without event sourcing by encoding four timestamps directly into rows.

Can a vector store be made bi-temporal?

You can attach timestamp metadata to embeddings, but that does not make a vector store structurally bi-temporal. Metadata filtering lets you exclude old vectors, yet the store still weights matching results by similarity, not by which fact superseded which. Sentra builds time into the graph structure itself, so a superseded fact is marked invalid rather than left to compete with the current one.

What is "valid time" vs. "transaction time" in plain English?

Valid time is when a fact was true in the real world. Transaction time is when your system learned it. Martin Fowler prefers "actual" and "record" as clearer labels for the same two axes, since a fact can become true before any system records it.

Does bi-temporal storage require more space or cost more to query?

It uses more storage because no record is deleted. Old facts are closed out and kept, so history grows over time. Point-in-time queries cost more compute than reading a single current-state table, though cached snapshots reduce that overhead for common views.

How does Sentra's graph differ from a standard knowledge graph?

A standard knowledge graph stores entities and relationships without tracking when each fact stopped being true. Sentra adds valid time and stop time to every fact and resolves meaning at ingestion against a per-organization ontology. Your agents can then ask both what is true now and what was believed at a past decision point.

Conclusion

A memory layer with one time axis cannot tell the difference between a fact that is true now and a fact that was once believed true. It collapses both into a single state, and the moment something changes, the old version either vanishes or lingers as if it still holds. For an autonomous agent reading that memory, the result is confident, fluent answers built on deprecated facts.

Sentra builds the second axis in at write time, invalidating old facts instead of deleting them and resolving meaning against a per-organization ontology. It runs as the memory layer beneath your agents and tools, so the systems already acting on your knowledge can finally tell when a fact stopped being true.