Temporal knowledge graphs: why Pluto breaks your graph

Until August 24, 2006, Pluto was a planet, no argument: the ninth of the solar system, taught in schools, listed as such by NASA. That day the International Astronomical Union voted a new definition of planet, Pluto failed the third criterion (it hasn't "cleared" its orbit of nearby bodies), and it became a dwarf planet. NASA itself has classified it that way ever since.

Now picture a corporate knowledge graph, or whatever grounds an AI assistant, holding the triple (Pluto, isA, Planet). On August 24, 2006, someone updates it to (Pluto, isA, DwarfPlanet), overwriting the old row. Technically correct today. But that overwrite just erased a fact that had been true for 76 years, with no trace left. Ask the system "was Pluto a planet in 1990?" and it can no longer answer, not because the data is missing, but because yesterday's data no longer exists.

This isn't an astronomy problem. It's the problem of every graph that treats facts as a current state instead of a history. And in a business, the exact same dynamic, triggered by a change just weeks old, produces wrong answers nobody notices until they get expensive.

What happens when two systems write the same fact?

A client has two systems feeding the same graph. On Monday the CRM writes (Company X, CEO, Alice). On Thursday the ERP writes (Company X, CEO, Bob). Without timestamps, the graph has two conflicting facts about the same relationship, with no way to know which scenario is the real one:

• The CRM has stale data, unrefreshed for months: Bob has been CEO for a while, Alice is noise.
• Bob really did replace Alice on Thursday: both facts were true, at different moments. That needs to be known, not overwritten away.
• They're co-CEOs, and the two systems record different views of the same moment, both correct.

A graph with no sense of time treats these three, radically different, scenarios as the same problem: "two conflicting triples, keep the one that arrived last." It's the most common shortcut, and it's almost always wrong.

Why does a graph without time produce contradictory answers?

There's a problem sneakier than two conflicting facts: inference chains that cross time. Take Kosovo's sovereignty. Until 1991, Kosovo was part of Yugoslavia. From 1991 to 2008, it was part of Serbia. Since 2008, it is no longer part of Serbia (though its full independence remains contested). Three facts, all true, never simultaneous.

If a graph flattens these facts onto a single row per relationship, an inference engine can conclude that "Kosovo is part of Yugoslavia" and "Kosovo is not part of Serbia" are both true at once, or mix a rule derived from one period with a fact only true in another. It's the same family of error as the ontology illusion: a structure that looks coherent but reasons over premises that were never true together.

Why this matters for AI in production

So far this reads like a logic-textbook exercise. It isn't, for three very concrete reasons.

First, point-in-time audits. If a regulator asks "what did the company know on March 15th?", a graph that has since overwritten its facts cannot answer. It's not a log-retention problem: the graph itself has stopped knowing what it believed true at that moment.

Second, wrong decisions from stale data nobody explicitly invalidated. A supplier raised its price 12% three months ago, but the graph still holds the old figure: query it today and a procurement agent quotes that stale number to a VP as if it were current, and the negotiation starts from the wrong baseline.

Third, and the most urgent one in 2026: an AI agent grounded in the graph to answer or act has no way to know it's using a stale fact, unless the graph itself carries that information. A RAG pipeline grounded on a time-blind knowledge graph can confidently cite a fact that was true last year and no longer is, and the answer sounds exactly as authoritative as the correct one.

One outdated passage in the context costs mainstream LLMs at least 20% of their performance, even when the current information was retrieved correctly: that is the measurement from the HoH benchmark, presented at ACL 2025, over 96,124 questions built from successive versions of real-world facts. The problem isn't the model: it's that you handed it a map with no dates on it.

The fix: model time, not just facts

The fix has a precise name and isn't new: bitemporal modeling, borrowed from relational databases and carried over into graphs. It distinguishes two time axes, and they must not be confused:

• Valid time: when the fact was true in the real world. Pluto's valid time as a planet runs from 1930 to 2006.
• Transaction time: when the fact was recorded in the system. If your graph only ingests that fact today, the transaction time is today, even though the valid time starts in 1930.

The two axes answer different questions. "What was true on March 15th?" is a valid-time question. "What did the system know on March 15th, with the data it had then?" is a transaction-time question, and it's the one an honest audit needs: you can have known something wrong, in good faith, with the data available at the time.

How do you implement a bitemporal knowledge graph?

The bitemporal principle translates into concrete techniques, and it's worth picking based on what you already run, not chasing whatever tool is trending:

• Named graphs and RDF-star are two distinct tools. A "named graph" groups a set of triples under a shared context, typically provenance: which system or source asserted that batch of facts. Annotating a single fact, with its own validity window or confidence level, needs a finer-grained mechanism: the emerging RDF-star standard lets you make statements about a statement: not just "Pluto is a planet," but "Pluto is a planet, per the IAU, valid from 1930 to 2006." The two combine well: the named graph says where a fact came from, RDF-star says when it was true.
• Event-based reification. Instead of modeling "Alice is CEO" as a static triple, you model the event as a first-class node: "Alice's CEO appointment," with a start date, an end date (if any), and the source that recorded it. The fact becomes a relationship with its own lifecycle, not a row to overwrite.
• Temporal query layers. Some graph databases already offer this natively: TerminusDB treats valid time as data and transaction time as part of its own commit graph, letting you query "what did the graph believe true on date X" without reconstructing it by hand. TigerGraph moves in the same direction by linking temporal events to the entities they touch, instead of treating timestamped data as an isolated series. Neither is the only valid choice: they're a reference point, not a platform lock-in.

The same principle already covered for ontologies and knowledge graphs applies here: the method matters more than the tool chosen. A bitemporal model can be built on an RDF graph, on a property graph, or inside a well-designed relational schema. The platform isn't the point.

In short

A graph that overwrites facts instead of keeping their history rarely fails loudly: it fails silently, confidently answering a question about the past using data from the present. Pluto stopped being a planet in 2006, but it was one for 76 years: a trustworthy graph needs to say both, with two different dates. Bitemporal modeling, named graphs with RDF-star, and event-based reification are the difference between a graph that describes only today and one that keeps the memory of how it got there, the only kind an AI agent can query without risking mistaking a dead fact for a live one.