Marty Sampson.aiAI, applied
Explainer · hand-authored example · no graph executed

When a fact changes, history should not disappear.

A temporal knowledge graph tries to preserve what was true, what is true now, and which source supports each answer.

Teaching model, not test output

The workshop records, graph and query results below are fictional and hand-authored. Graphiti, LightRAG and a graph database were not installed or run. No accuracy, latency, cost or comparative result is claimed.

Ordinary retrieval can find text that mentions a workshop. A temporal graph attempts something additional: represent the event, connect its schedule and location to dated source episodes, and keep a former fact available after a correction.

Three records, one contradiction

  1. E1 · March 3
    “The neighborhood workshop is Saturday at the library.”

    At this point, Saturday and the library are the current schedule.

  2. E2 · April 10
    “Correction: the workshop moved to Sunday at the community center.”

    This later episode supersedes both schedule facts.

  3. E3 · undated
    “Join the workshop Saturday.”

    The flyer contradicts the correction, but has no date or location. It is evidence of what the flyer says—not sufficient evidence of the current schedule.

Recorded time is not automatically valid time. For this teaching example, E2 is assumed to take effect when the correction is recorded on April 10. A real source might announce a change that becomes effective later—or describe one that happened earlier—so those two timestamps should be stored separately when the evidence provides them.

Original conceptual diagram

One event, changing facts, retained provenance

Source episodes

E1Mar 3 · Saturday · library
E2Apr 10 · Sunday · community center
E3Undated flyer · Saturday

Derived facts

Historicalday → Saturdayvalid until Apr 10 · source E1
Historicalplace → libraryvalid until Apr 10 · source E1
Currentday → Sundayvalid from Apr 10 · source E2
Currentplace → community centervalid from Apr 10 · source E2

Answer context

Question chooses a time.Current and historical queries should select different fact edges.
Every selected fact carries support.An answer can link back to E1, E2 or E3 instead of citing “the graph.”
E3 is retained, not promoted.The conflicting flyer remains inspectable. Without a date, it should not replace the dated correction.
Arrows are expressed as labeled relationships in the fact cards. “Current” and “historical” are conclusions encoded in this fictional model, not results extracted by software. The diagram assumes E2's recorded time and effective time are both April 10; a document timestamp does not establish that equivalence by itself.

Four questions reveal four different jobs

QuerySupported answerEvidenceWhy
When and where is the workshop now?Sunday at the community center.E2The query asks for facts current after April 10.
What was the plan on March 3?Saturday at the library.E1The query asks for the historical state before the correction.
What day does the flyer claim?Saturday.E3This is a source-specific question; it does not ask what is current.
How much does the workshop cost?Not established by these records.NoneA graph should not manufacture an edge that no episode supports.

The same word—Saturday—can support a correct historical answer, a correct description of the flyer, or an incorrect current answer. Similarity alone does not decide which job the question asks the evidence to do.

Episode, entity, fact and retrieval result are not synonyms

Episode
A source record as ingested. It preserves provenance and wording.
Entity
A represented thing—in this example, the workshop and its locations.
Fact or edge
A derived relationship such as workshop → scheduled day → Sunday, with source and validity.
Retrieval result
The subset selected for a particular query and assembled into model context.

Keeping these layers separate helps diagnose mistakes. If “Sunday” never became an edge, extraction failed. If the edge exists but E1 was selected for a current query, retrieval failed. If E2 entered context and the answer still says Saturday, response generation or review failed.

A graph makes structure explicit; it does not make it true

  • Entity extraction can merge two events or split one event into duplicates.
  • A relationship can be inferred incorrectly or attached to the wrong source.
  • Dates can be missing, ambiguous or refer to the document rather than the fact.
  • An ontology can force messy reality into categories that lose important nuance.
  • Correct graph data can still be retrieved poorly or misused by a model.
  • Making relationships easy to traverse can increase privacy risk. Access, correction and deletion rules still matter.

Retaining superseded facts can be useful for historical questions, but it is not an unconditional virtue. A requirement to delete sensitive data takes precedence over keeping a perfect timeline.

Two documented approaches

Graphiti: temporal facts and episodes

Graphiti’s repository documents entities, facts with validity windows, source episodes and hybrid retrieval over a temporal knowledge graph. Those concepts inform the vocabulary here. The workshop graph and all query answers are original teaching material.

LightRAG: graph-enhanced retrieval

LightRAG’s repository and paper describe a graph-enhanced retrieval approach using entities and relationships with local and global retrieval. This article does not reproduce its architecture or claim its reported performance.

Primary sources checked. Listing these projects does not imply installation, adoption, compatibility or endorsement.

Related: Context is not memory →

Back to field notes