Citation Needed: Provenance for LLM-Built Knowledge Graphs

When an LLM produces a fact that never appeared verbatim in its inputs, how can you trace where it came from? A summary, extracted fact or structured record can combine several sources through nondeterministic interpretation. That synthesis can erase the paper trail. Provenance preserves how an artifact was built and why—information needed for debugging, evaluating source trust, deciding what to delete and supporting legal compliance.

Daniel Chalef’s team built Graphiti, an open-source temporal graph framework underlying Zep’s enterprise agent memory infrastructure. Its inputs extend beyond chat: voice transcripts, email and business data all contribute context. Once these sources become agent memory, two questions recur: where did a fact come from, and how trustworthy is its evidence?

Consider the talk’s stylized healthcare example. An agent retrieves a confident statement: the patient has a penicillin allergy. Its context was synthesized from a lengthy electronic health record, a PDF lab report and an AI intake chat. If the allergy information came from the patient’s own chat message, presenting it to a treating doctor without that origin can mislead. The presence of clinical documents elsewhere in the input does not establish that they supplied this particular fact. The retrieval needs to expose both the exact source and the basis for trusting it.

A source_id works well when a warehouse or data-lake pipeline copies or deterministically transforms a value from known inputs. An LLM context pipeline introduces several different changes:

• Synthesis: each extracted fact may depend on one or more of the sources supplied in a prompt.
• Identity resolution: Jay Smith and John Smith may become one entity whose facts originate in different places.
• Invalidation: new information may contradict an old fact, changing what the store knows beneath an existing pointer.

Chalef argues that an append-only change log becomes difficult to manage as these mutations accumulate. The requirement is an evolving set of source relationships that survives the mutations themselves.

Graphiti calls source records episodes. In the healthcare example, three episodes supply the input data. The extracted patient and penicillin entities are connected by an edge; together, those two entities and their relationship form a triple that can be rendered as the allergy fact. Relationships back to the episodes make source attribution a graph walk.

Creating those links on the first write is straightforward. Preserving them requires rules for every mutation. When two entities merge, the merged entity must retain the union of their source links; otherwise, identity resolution silently removes evidence. When new information contradicts a fact, the graph must preserve the lineage of that change as well. The described invalidation operation adds a date to the affected edge and records the episodes responsible for invalidating it.

The talk calls the invalidation date invalidAt. Current Zep fact documentation uses invalid_at for when the fact ceased to hold in the world and expired_at for when the system learned the change. These are different clocks: the event and its later discovery need not coincide. The architectural point is that both derived facts and changes to those facts remain connected to their source data.

Metadata projection carries source classifications into derived context. At ingestion, an episode originating in an EHR receives an EHR tag. Entities and facts derived from that episode inherit the tag, allowing retrieval to filter for the relevant clinical-source classification while traversing the graph. One tagging operation at ingestion supports later evaluation of the evidence.

Multiple parents make the policy more interesting. Suppose a fact has three parent episodes and one is unverified. Whether that fact is sufficient for an action depends on the consequences of being wrong.

The allergy policy retains a warning even when its evidence is patient-reported. The consent policy withholds authorization unless all supporting parents satisfy verification. The same graph shape therefore supports opposite decision rules.

The graph exposes evidence; the agent applies the business rule. Graphiti can expose which parent episodes have a tag, but it does not determine the appropriate risk policy for every application. This distinction also matters when implementing filters: current Zep metadata projection documentation says a search result matches when at least one associated episode satisfies the filter. Combining predicates with AND requires those predicates to hold within that episode; it does not establish that every parent is verified. An all-parent consent rule needs that separate evaluation.

Retention policies and right-to-be-forgotten requests introduce another mutation: deleting source data. Lineage identifies the facts affected by that deletion, but a fact can have other surviving support. In the deletion example, the intake chat is one of three episodes supporting the allergy fact. Removing that chat leaves the EHR and lab-report episodes, so the allergy fact survives. A contact-preference fact supported only by the intake chat disappears. Delete a fact only when no remaining episodes support it.

The support-set operation can be expressed directly in Python. This models the proposed deletion of the intake chat and the resulting fact associations:

supports = {
    "penicillin_allergy": {"ehr", "lab_report", "intake_chat"},
    "contact_preference": {"intake_chat"},
}
deleted_episodes = {"intake_chat"}

remaining_supports = {
    fact: parents - deleted_episodes
    for fact, parents in supports.items()
}
retained_facts = {
    fact: parents
    for fact, parents in remaining_supports.items()
    if parents
}
deleted_facts = set(supports) - set(retained_facts)

assert retained_facts == {
    "penicillin_allergy": {"ehr", "lab_report"}
}
assert deleted_facts == {"contact_preference"}

This rule concerns support associations. Current Zep deletion documentation specifies additional limits: shared-node names and summaries are not regenerated and can retain information from a deleted episode. Deleting an episode that invalidated a fact also does not restore that fact. Association-based cleanup therefore does not, by itself, establish complete erasure.

Because deriving context is lossy and generative, lineage needs to be engineered into the data structure instead of reconstructed from logs afterward. Graphiti retains source content verbatim and links derived artifacts back to it. Those links support source verification, debugging and deletion decisions, as well as compliance workflows. Most of the capabilities described in the prepared talk are available in Graphiti’s repository.

Supporting compliance is not the same as guaranteeing it. Chalef’s companion article places request handling, verification and auditing around deletion propagation. The graph provides the dependency information those processes need.

That information has a construction cost. Chalef describes Graphiti-style graph construction as expensive and says the team has invested in reducing the cost and latency of generating graph artifacts. The recording supplies no quantitative cost or latency result. His closing slide offers Zep on the left and Graphiti on the right before the discussion turns to implementation questions.

A question about changing relevance weights exposes a boundary in the graph-centric design. Chalef says that capability belongs to Zep, not Graphiti, and that its provenance tracing uses a separate data structure outside the graph. For this particular problem, not all provenance is represented by graph relationships.

Asked about entity and edge creation, Chalef first describes how agents retrieve graph artifacts:

• Vector similarity search finds textual artifacts by semantic similarity.
• Full-text search finds textual matches.
• Graph operations, including breadth-first search, follow relationships.

The available operations depend on the underlying graph database. Whichever route leads an agent to an artifact, its provenance can then be inspected. This explains access to evidence, rather than specifying how entity or edge types are chosen.

The next question goes underneath episode ingestion. Episodes are themselves graph nodes, and other derived artifacts can also be nodes because they need their own lineage. Adding an episode runs a pipeline whose high-level sequence is:

1. Extract structure: identify entities, relationships and candidate facts. A hydrated fact triple has a subject, verb and object.
2. Deduplicate entities: reconcile newly extracted entities with identities already in the graph.
3. Deconflict facts: compare new facts with existing ones and invalidate those that the new evidence changes.

The pipeline must therefore handle both additions and mutations; extracting triples alone is insufficient.

Chalef illustrates deconfliction with a preference. Initially, Daniel loves Adidas shoes. Three months later, the shoes fall apart, he returns them and includes an angry message. The new evidence yields facts that Daniel returned the shoes and was unhappy with Adidas. It also invalidates the older preference. Retaining both statements without accounting for the change would leave the agent with stale context.

Although much of the pipeline uses LLMs, the team tries to avoid them where conventional techniques suffice. Chalef names information retrieval, traditional NLP, entropy-related techniques and SimHash among approaches used for deduplication. He describes these alternatives as cheaper, faster and more deterministic than LLM processing, without reporting numerical comparisons.

Files, wikis and Markdown knowledge bases offer another way to represent agent memory. The audience asks whether Zep is pursuing that direction and whether these provenance ideas transfer. Chalef identifies a specific difficulty: after an agent mutates lines in a file, understanding why those changes occurred and which sources justified them becomes hard.

The burden grows in multi-agent, multi-user and multi-source settings. Chalef says Markdown works well for desktop usage and sometimes for server-based agentic applications. His objection concerns the enterprise problems his team encounters, particularly maintaining provenance at scale; it is not a claim that file memory fails in every setting. The answer does not establish a Zep roadmap for file-based memory.

The final question asks how memory is written back: explicitly or implicitly, through a conversation summary or at every turn, and by which component. Chalef describes the extraction design rather than specifying its trigger cadence. A single-shot LLM extraction produces entities, relationships and facts together.

Chalef attributes inexpensive extraction to that consolidation. Reflection then checks accuracy and enriches the lineage: the goal is to capture why an artifact changed, beyond recording that two artifacts are related. He places the described functionality partly in Graphiti and partly in Zep without assigning each individual step to a product. The resulting memory needs to preserve not only the latest fact, but the evidence and change history that make that fact intelligible.