Time Is a Fact Too

Why our knowledge systems remember everything except when things changed

A few years ago I was debugging a data pipeline that had been silently producing wrong outputs for weeks. The records were all there. The values were all correct. But the system had no idea that a field had changed its meaning halfway through the year – what used to mean “approved” now meant “pending review.” Every query returned confident, accurate, chronologically confused answers. That experience stuck with me. The pipeline wasn’t broken. It was timeless in the worst possible way it had excised time from its model of reality entirely. This is, it turns out, the default setting for most knowledge systems we build today.

AI Generated Image about the idea of the blog

Facts Without a Clock

Modern retrieval systems —- especially the Retrieval-Augmented Generation (RAG) architectures that have become ubiquitous —- operate under a quiet but consequential assumption: knowledge is static. You embed documents. You retrieve relevant chunks. You generate an answer. This works beautifully for questions like “What is Kubernetes?” or “Who founded company X?”

Diagram (editable Draw.io): Temporal Knowledge Systems Diagram

It starts to fail when you ask: “Who was the CEO in 2018 when the series A funding happened and who were the investors?” or “What changed after the funding round?”

These aren’t harder questions because they require more facts. They’re harder because they require reasoning over time — understanding that the same entity can be in different states at different moments, and that the sequence of those states is itself meaningful. Recent research has called this out explicitly: RAG systems largely ignore the temporal nature of knowledge, often returning answers that are factually correct but chronologically wrong. This is not a retrieval bug. It is a structural assumption baked into the architecture.

The failure is not that systems forget old facts. It is that they never understood time in the first place.

Reality as a Sequence, Not a Snapshot

Consider a simple company timeline:

— Founded, uncertain
— Seed round, expanding
— Series B, validated
— CEO leaves, unstable

A traditional knowledge system stores these as independent entries — parallel truths with equal standing. But they are not parallel. They are a narrative. The meaning of “CEO leaves in 2006” is entirely different if you know that it followed a funding round than if you don’t. The facts are the same. The causal context is everything. This is closer to how humans actually reason. We don’t retrieve isolated facts — we reconstruct sequences. We remember that the promotion came after the product shipped, that the resignation came before the acquisition fell through. Memory, for us, is fundamentally temporal.

The Git Intuition

There’s a useful analogy here from software engineering. In Git, nothing is deleted — everything is versioned, every state is reconstructable, every change is explicit. You don’t store the current state of a file; you store its history. Now apply that to knowledge. A CEO doesn’t just “exist in a system” — they take a role and leave it. A company doesn’t just “have funding” — it raises, spends, and sometimes runs out. A product doesn’t just “exist” — it launches, iterates, gets deprecated. Instead of storing CEO = Alice and CEO = Bob as competing facts (which is, embarrassingly, what most systems do), you store:

Alice (CEO: 2000–2006)
Bob   (CEO: 2006–present)

This sounds obvious. But it introduces something that most retrieval pipelines are not designed to handle: time, state transitions, conflicting truths that are both correct, and causality. The moment you take time seriously, the architecture has to change.

Temporal Knowledge Graphs and Their Limits The research community has been working on this under the umbrella of Temporal Knowledge Graphs (TKGs). The key shift is extending the standard knowledge graph triple — (entity → relation → entity) — with a temporal dimension: (entity → relation → entity → time interval). This allows systems to distinguish identical-looking facts across different periods and answer time-scoped queries with more precision. But even this is insufficient, because knowing when something happened is different from knowing why it happened.

A more useful abstraction treats events — not facts — as the fundamental unit. Instead of storing ABC → raised → $5M as a static triple, you store an event: a seed round, dated, with participants, connected to what came before and what followed. Events can be ordered, linked, and explained in ways that facts cannot. Recent work on event-centric graphs is moving in this direction, building representations that support reasoning over sequences rather than lookups against isolated entries.

The question is not “what is true?” but “what became true, and when, and what made it so?”

The Hard Parts Are Not Where You Think

Given all this, it’s tempting to think the engineering problem is mostly one of storage — attach timestamps, query by time window, done. In practice, the difficulty is elsewhere. Temporal retrieval requires more than filtering by date. If someone asks “what led to the CEO leaving?”, the system must identify the relevant time window, trace preceding events, filter noise, and construct a coherent causal chain. This is structured reasoning, not keyword search. Causality versus correlation is a deeper trap. The fact that a funding round happened in 2005 and the CEO left in 2006 does not mean one caused the other. Temporal systems risk overfitting narratives — inventing causality from sequence. Most current models capture order but struggle with explanation. Query understanding is the final hurdle. Users don’t think in SQL. They ask “how did this company evolve?” or “why did things go wrong?” — questions that each imply a different retrieval strategy, a different temporal slice, a different level of causal depth. Routing these correctly remains an open problem.

Why This Matters Beyond Databases

The implications extend well beyond company intelligence tools. Consider personal knowledge systems — the note-taking apps, second-brain tools, and writing environments that have proliferated in recent years. Their fundamental promise is synthesis: not just capturing ideas, but connecting them. Yet most of them treat your notes as a flat, timeless repository. They cannot tell you how your thinking about a topic has evolved, or which ideas keep recurring in different forms across years. Time is the organizing principle that’s missing. Not tags. Not embeddings. Time. The same applies to AI memory systems more broadly. Agents that interact over long periods need evolving context — the ability to remember not just what was said but when, and to recognize that something that was true six months ago may no longer be. Without a temporal model, memory collapses into noise, with older and newer facts competing as equals.

A Realistic Assessment

This space is active. There are systems that build temporal graphs, retrieve time-scoped subgraphs, and support incremental updates. There are frameworks attempting to enforce temporal consistency and reduce contradictions at query time. The theoretical foundations are reasonably solid. What remains open is the layer above: usable abstractions for developers, intuitive query interfaces for users, and reliable causal reasoning that goes beyond sequence to explanation. The hardest part is not representing time — it is reasoning about why time matters for a given question.

There’s something quietly profound in this problem. The reason static knowledge systems work as well as they do is that most questions we ask are, implicitly, present-tense — what is, not what was or what became. But the questions that matter most — in business, in science, in personal reflection — are almost always about change. How did we get here? What shifted? What would have been different if X had happened before Y? A system that can answer those questions is not just more accurate. It models reality differently — as a thing that unfolds, not a thing that simply is. The world is not a database. It is a timeline. Building systems that treat it as one is still, largely, ahead of us.