How to Keep Graph Facts From Going Stale With Expiration Policies

Graph facts go stale because relationships change but the records do not. Expiration policies set clear boundaries on when a fact stops being true. This stops your system from using old information to answer questions about right now.

Why graph facts expire and why most enterprise graphs ignore it

A knowledge graph stores simple statements called triples: a subject, a relationship, and an object. For example, "Alice manages Project X." That structure records the relationship but says nothing about when it holds. Without a time dimension, you cannot tell a current assignment from an old one. You also cannot look back to see what was true at a specific moment. The missing piece is not another fact about Alice or the project. It is a boundary around the relationship itself.

MemPalace (a knowledge graph system) shows the problem clearly. Say a project assignment was true in June 2025 but false by March 2026. A traditional graph would still return it as current. Nothing stored in the relationship says otherwise. The system returns a wrong answer with the same confidence as a right one. The reader has to spot a change the graph cannot represent.

In large organisations, project assignments, job responsibilities, and technology choices can change in weeks. But updates to the graph can arrive months or years later. That gap makes stale context a structural problem, not just a missed edit. Searching documents for similar passages does not fix it. An old account and a new one can both closely match a question. When both come back together, there is no reliable way to tell which one still holds. Retrieving more context cannot replace a clear statement of when a fact is valid.

What a validity window is and what the data model needs to support it

A validity window records when a fact started being true and when it stopped. A graph can store those boundaries in fields called valid_from and valid_to. A blank valid_to field, using the value NULL, means the fact is still active. Queries must check for that blank value explicitly. Skipping that check can make ongoing facts disappear from results entirely. The data model and the query rules have to agree on what an open window means.

A fully bi-temporal model (a model that tracks two separate timelines) separates world time from recording time. World time describes when the fact was actually true. Recording time describes when the system stored it and when the system stopped treating it as current. Graphiti (a knowledge graph framework) puts this into practice with four timestamps on every relationship edge: valid_at, invalid_at, created_at, and expired_at. The first pair covers world time. The second pair covers recording time. A fact entered in 2026 about an event from 2024 makes the difference concrete. The event date and the entry date answer different questions.

When a new fact replaces an old one, the old relationship is closed rather than deleted. Its end boundary is set, and a new relationship opens. The earlier record survives. This means a query can rebuild what was true at any chosen moment, or what the system believed at that moment, depending on which timeline you use. Production systems also need timezone-aware dates in a standard format called ISO 8601 UTC. This stops dates at the boundaries from being off by a day. Indexing the validity fields keeps time-based filters fast, even in large graphs.

How to decide which facts expire and how quickly

Expiration policy starts with the type of relationship. "Is CEO of" changes on a different schedule from "was founded in" or "holds licence number." A single time-to-live rule, often called a TTL, can close slowly changing facts too soon. It can also leave fast-changing facts active too long. Give each category of relationship its own default window. Allow individual facts to be overridden. This makes those choices clear.

Keeping a record and keeping it marked as current are two different things. Legally required records may need to be kept forever. But operational data, such as project assignments, role memberships, and system settings, may need to be closed or archived after a set period. You can keep a fact even after it stops being current. An operational relationship can be closed while the evidence that it once existed is preserved.

HALO, a framework published at WWW Companion '25 by researchers from Dalian University of Technology and RMIT University, treats facts as having their own individual rates of change rather than a shared lifespan. Its framework predicts a per-fact half-life, giving facts that change often a shorter half-life than stable ones. This means they do not all share a uniform TTL. The OpenAI temporal agents cookbook recommends numeric scores that combine how recent a fact is, how trustworthy its source is, and how often it is queried. These scores help decide what to archive. They show how much context is worth keeping, while validity windows show whether a fact can still support a claim about what is true now.

Fill in expiration dates carefully, using evidence such as document publication dates or recorded system changes. Never guess them. A careful approach may keep some history longer than needed, but you can fix that later. Setting boundaries too aggressively can silently close facts that are still true. Setting up expiration on old data needs the same care as ongoing expiration. An unsupported boundary can mislead just as much as no boundary at all.

What knowing a fact's source adds to expiration policy

A date range says when a fact holds, but not why that range deserves trust. Tracing a fact back to its source fills that gap. It links the fact to the input that produced it, such as a support ticket, a document, a CRM update, or a conversation. Graphiti traces entities and relationships back to those source records. That connection gives expiration policy a practical trigger beyond the passage of time. When a source changes or is withdrawn, the system can find the facts whose validity needs review.

This is more precise than treating every fact about the same subject as suspect. A changed source may replace one specific relationship without cancelling everything else known about that subject. Source tracing finds the exact dependency that needs attention. It also supports a decision about whether to close its window. Without that connection, the graph can hold onto a derived fact after the evidence behind it has gone. The fact may still look complete even though its supporting evidence is out of date.

How reliable a source is also affects how quickly a fact should expire. MemPalace includes a confidence field on triples that defaults to 1.0. It allows lower values for facts that were inferred or came from less reliable sources. That field gives you a place to mark weaker evidence. But the default value alone does not make those distinctions. Confidence scoring needs to reflect how reliable a source actually is before it can guide expiration decisions. For a decision record to be traceable, the chain must extend from the action back to its supporting facts, then to their sources, and to whether those sources were current at the time.

How stale graph facts corrupt automated workflows and AI agent decisions

Once an agent acts on graph context, a stale fact becomes more than a wrong answer. Consider a workflow that reads a role assignment to decide who should receive a message. If that assignment has expired without being marked closed, the workflow can follow its instructions correctly and still send the message to the wrong person. By the time someone notices, the message has already gone.

The risk grows when the same kind of role fact is used to decide who gets access to a system. An agent may grant access based on a responsibility that no longer exists, even though the action appears authorised by the graph. Sending the wrong email may be fixable. Granting access or releasing funds may not be. Both how visible the mistake is and how easily it can be undone matter here. A quiet error with lasting consequences needs stronger controls than a visible mistake that can be corrected quickly.

Before an agent relies on a fact, the system should confirm that its validity window covers the current moment. It should also confirm that the fact's source has not been replaced. The OpenAI temporal agents cookbook describes an Invalidation Agent that checks incoming facts and handles statements made out of date by newer ones. Running faster only makes the problem worse if the system checks how to act but not whether the conditions supporting that action still hold.

The oversight layer that makes expiration policy work in practice

A validity field does not enforce a policy by itself. Approval steps, access controls, and named exception owners make the system follow the policy. The right to read facts and the right to change their boundaries need to be separate. An agent that uses facts to make recommendations should not also be able to close or extend those facts without a person approving the change. Requiring approval before closing a replaced relationship or extending an expiration date creates a clear record of those changes. Without that, a graph can have a detailed history with boundaries that look plausible but were never reviewed.

Permissions can also rest on facts that expire. An agent authorised under a particular role assignment or configuration may end up with more access than it should have when that underlying condition changes. Review permission boundaries when the graph's fact structure changes in a meaningful way. This connects expiration policy directly to the risk of actions that are hard to undo. Rejecting stale evidence is not enough if the authority to act still rests on the same stale condition.

Monitoring catches changes that fixed rules cannot foresee. If an agent starts reading far more facts than usual, or moves into areas it does not normally touch, oversight systems should flag it before the work continues. Timing matters here. Catching a problem after an irreversible action has taken place does not offer the same protection. With a named person responsible for exceptions, those flags reach someone who can resolve doubts that would otherwise go unnoticed in the pipeline.

Nodes is one example of a system that builds a connected map of company records to find where money is being lost between systems. It carries out fixes only when a person says yes. Like any system that acts on graph-based context, it depends on fresh, valid facts. The underlying principle applies more broadly: the authority to act and the evidence for acting both need to rest on current foundations.

How a graph that enforces expiration builds lasting institutional knowledge

Closing replaced relationships instead of deleting them creates a record you can query. Past decisions stay connected to the facts that supported them and the outcomes that followed. That history makes it possible to judge a decision against the conditions that existed when it was made.

This value survives a change in models or agents. A company-owned graph keeps its time-bounded history, business rules, and decision records separate from any single model. A replacement can use that context without rebuilding institutional knowledge from scratch. Expiration preserves the difference between knowledge that can be reused and conditions that need to be checked again.

Outcomes need the same discipline as the facts that supported the work. The graph should record what the agent recommended, what it read, what was approved, and what resulted. This way, comparisons use the same time context. Keep estimates separate from observed outcomes. Keep time saved separate from money saved. Otherwise, the record can make past performance look cleaner than it was, and weaken the next decision.