What Is a Bi-Temporal Knowledge Graph? (and Which Platforms Provide One for Company Knowledge)

TL;DR

• A bi-temporal knowledge graph tracks every fact on two clocks: valid time, also called effective time (when the fact was true in the world), and transaction time, also called recorded time (when the system learned it).
• One timestamp cannot answer both "what is true now" and "what did we believe in March". Old facts are invalidated, not deleted, so the record stays auditable.
• Document version control (SharePoint, Confluence, Guru) keeps versions of pages and who approved them. It does not track individual facts across sources, so it cannot tell an agent which fact is current when an email contradicts a wiki page.
• Sentra is a bi-temporal knowledge graph for company knowledge: every fact carries when it became true and when it stopped, its source and its permissions, and a named person approves before Sentra acts or sends anything. XTDB and Zep's Graphiti are bi-temporal infrastructure you build on.

Definition

A temporal knowledge graph tracks at least one of these. A bi-temporal one tracks both, separately, on every fact. A plain knowledge graph tracks neither, so a changed fact simply replaces the old one.

What "bi-temporal" actually means

A bi-temporal knowledge graph is a graph of facts in which every fact carries two independent kinds of time: valid time, the period during which the fact is true in the real world, and transaction time, the period during which the system recorded it as believed. The terms come from Richard Snodgrass, whose work influenced the SQL:2011 standard. Martin Fowler finds those labels confusing and prefers actual time and record time, and notes that other sources call actual time "effective" time. All three pairs 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.

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 is asked, "What was the Pro price on March 5?"

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

Holding both answers forces four timestamps onto every fact. 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 closes, 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.

Fowler's payroll example makes the same point with Sally's salary: a raise reported as effective February 15, then corrected on April 5. You cannot answer both "what was true" and "what did we know" with a single date.

Why one timestamp is not enough

Store only valid time, and you can say what was true on a given date, but you lose any record of what the system believed when it made a decision. An 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.

For an AI agent, that gap becomes a behavior problem. An agent reads facts and acts on them, so a memory layer that cannot separate "true now" from "believed then" gives 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, with full confidence.

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 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 rule is what lets you ask both "what is true now" and "what did we think in March" and get a correct answer to each.

The two axes behave differently. Valid time can be corrected retroactively, because the world's truth can turn out to have been different from what was recorded. Record history cannot be rewritten, only extended. As Fowler puts it, "We don't change what we thought we knew about Sally's salary on Feb 25" (martinfowler.com).

Single-temporal vs bi-temporal: a quick comparison

The single-temporal column describes most flat vector stores and conventional databases. The bi-temporal column describes a graph where every fact carries a valid interval and an end time, and old facts are invalidated rather than removed.

Why AI memory specifically needs this

A person who pulls a stale pricing doc usually catches the error through context. An agent treats whatever it retrieves as fact and acts on it, quoting a deprecated price to a customer or running a workflow against a policy that was rescinded last quarter.

Flat vector stores make this worse because they weight old and new text equally. 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. You can correct what was true in the world without erasing what the system once believed. 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. Both are reads of the same graph.

Bi-temporal platforms for company knowledge: what to require

When a company asks which platform keeps company knowledge temporally consistent, the common answer is document version control. SharePoint keeps major and minor versions, can require content approval for submitted items, and can require check-out before editing (support.microsoft.com). Confluence creates a new version each time a page is modified, and restoring an older version copies it in as the current one (confluence.atlassian.com). Guru assigns a verifier to each card with an interval from 30 days to a year (help.getguru.com).

All three version documents, not facts. They record when a page changed. They do not record when the fact inside it took effect, and they cannot see the email, meeting or ERP record that contradicts the page. For agents, a platform needs five capabilities.

1. Effective time and recorded time on every fact. The price took effect on March 1; the system learned it on March 15. Both are stored and both are queryable.

2. Supersession. A new fact end-dates the one it replaces, across sources. If a Slack decision overrides a Confluence page, the page's claim is marked superseded, not left to compete.

3. Source on every fact. Every answer links to the message, meeting or record behind it.

4. Source permissions. Each fact keeps the access rules of the source it came from, so an agent never sees what its user could not open.

5. Approval by a named person. Before anything is sent or acted on, a named person signs off.

Which platforms provide this

XTDB is an open-source (MPL 2.0) immutable SQL database that builds on the bitemporal capabilities in SQL:2011 (docs.xtdb.com). Valid time is user-managed and system time is the audit history of every change, with non-destructive updates stored as new rows (docs.xtdb.com). It is the right base when you are building a system of record and will write the ingestion and fact model yourself.

Zep and Graphiti. Graphiti is Zep's Apache 2.0 temporal graph engine: each fact has a validity window, old facts are invalidated rather than deleted, and every entity traces to the episodes that produced it. The self-hosted reference servers ship with no authentication or authorization (github.com). Zep's managed service adds attribute-based access control and SOC 2 Type II (getzep.com). See Graphiti explained and Sentra vs Zep.

Approaches to bi-temporal data, compared

Bi-temporal ideas show up in graph engines, databases and the SQL standard, each built for a different job. Each entry below was checked against its own documentation on 5 November 2026.

Zep and Graphiti. The Zep paper describes two timelines: T, the chronological order of events, and T′, the transactional order of ingestion, which serves database auditing. Each edge carries four timestamps, and when a new edge contradicts an overlapping old one, Graphiti sets the old edge's t_invalid to the new edge's t_valid, giving priority to newer information.

SQL:2011 temporal tables. The standard defines application-time periods (valid time) and system-versioned tables (transaction time). MariaDB combines both in bitemporal tables. SQL Server's temporal tables are system-versioned only: the engine records when each row version was current and answers FOR SYSTEM_TIME AS OF queries, but valid time is left to the application. XTDB notes that the bitemporal features in SQL:2011 lack significant adoption (docs.xtdb.com).

Datomic keeps every transaction and offers as-of, since and history views of the database, all on transaction time (docs.datomic.com).

The databases give you the two clocks and leave the rest to you: deciding what a fact is, which source to trust, and who may see it. Graphiti adds fact extraction for data you send it. Sentra does that work for company knowledge from the systems the company already runs.

How Sentra implements bi-temporal memory

Sentra builds these principles into a working layer that sits beneath your agents and tools. Write-time comprehension resolves information into facts before storage, against a per-organization ontology, rather than rediscovering meaning on every query. Vector-based RAG works the other way around: it stores embeddings, then guesses at structure each time an agent asks.

When a new fact contradicts an old one, Sentra invalidates the old fact instead of deleting it. Each fact carries when it became true and when it stopped being true, so an agent can ask what is true now and what was true in March and get two correct answers. Provenance stays first-class: the system shows where a fact came from and when it changed, and flags contradictions and stale facts across sources.

One org-wide graph reads from more than 200 tools, including Gmail, Slack, HubSpot, GitHub, Notion, Linear and ERP and HRIS systems, and serves people and every agent over MCP and REST. A correction made once reaches ChatGPT, Claude, Copilot, Gemini and internal agents alike, and each answer respects the permissions of its source. A named person approves before Sentra acts or sends anything. Sentra holds SOC 2 Type II and ISO 27001 and runs in the cloud, an isolated VPC or air-gapped on-prem. For the wider picture, see what organizational memory is and why AI agents forget.

In practice, each fact is linked to one source record, such as a meeting, an email thread, a Slack conversation or a CRM record, with the time the event happened and the time Sentra stored it. When sources disagree, Sentra answers from the newer one and says that the older one disagrees, citing both. A correction made in chat is stored as a new dated fact, the earlier fact is not erased, and facts a person edited or deleted survive every later sync. How Sentra keeps company memory current walks through each step, and how Sentra enforces permissions on every fact covers the access checks.

Book a demo at /demo to see the current fact, its history and its source for your own company knowledge.

FAQ