Chapter 3 built the strongest conventional retrieval the book could assemble and left it standing. That result constrains this chapter before it begins. Any claim of the form retrieval finds text but does not understand it would be false about the system Chapter 3 actually built: a hybrid retriever, a cross-encoder reranker, and a capable reader already perform substantial interpretation at query time. The reader distinguishes proposals from decisions when the passages allow it, follows rationale across artifacts, and abstains when evidence runs out. That is understanding, deployed per query and discarded afterwards.

The question is therefore sharper than the usual argument for structured memory:

What do we gain by preserving AI-derived understanding as reusable state rather than reconstructing it from raw evidence independently on every query?

The chapter’s answer has two halves. The first is architectural: a persistent derived graph built with Microsoft GraphRAG, inspectable, versioned, and rebuildable, with raw history remaining authoritative underneath it. The second is experimental: on the current local workload, strong conventional RAG remains extremely competitive, the graph does not produce a general quality win, and its costs are large. Its value is conditional — relational reuse, corpus-wide synthesis, and downstream mechanisms that consume persistent structure — and its mistakes, unlike a reader’s, persist.

RAG already understands

The strawman version of this chapter would say that retrieval matches words while graphs understand meaning. Nothing in the book’s own evidence supports that division. Chapter 3’s reader receives up to six passages and reasons across them jointly; the reranker scores query and passage together before the reader ever sees them. When the frozen comparison in this chapter asks what event store should new services use?, the baseline answers PostgreSQL, cites the decision record, and does so from the same raw passages any graph condition sees. Interpretation happened. It happened at query time, inside one inference, and it left no trace.

That observation reframes the entire enterprise. The transition this book studies is not from dumb matching to smart comprehension. It is from transient interpretation to persistent interpretation:

RAG interprets history for this query. Persistent graph memory preserves some of that interpretation for future queries.

Everything the graph stores — an entity, a relationship, a claim, a community summary — is an assertion of the form an AI system read these passages and concluded this. Each one amortises repeated reading: the tenth question about the event-store migration need not re-derive that PostgreSQL replaced SQLite from raw sessions if a relationship already says so. Each one also fossilises fallibility: if the extraction was wrong, the tenth question inherits the error without re-reading the evidence that would have corrected it. Reusable intelligence and reusable mistakes are the same mechanism. The experiment measures both.

What disappears after the answer?

Consider what the baseline knows at two moments. During inference on why was PostgreSQL chosen?, its context contains the contention report, the benchmark, the incident, and the decision record, and its activations transiently encode the connection between them. One second later the answer is delivered and that connection is gone. The passages remain in the index. The understanding does not.

Three consequences follow. First, every query pays the full price of interpretation: retrieval, reranking, and reading start from raw text regardless of how many times the same connection was already derived. Second, nothing accumulates: twenty questions about the migration leave the system exactly as knowledgeable, in any stored sense, as zero questions did. Third, consistency is accidental: whether what did we decide?, why?, who proposed the alternative?, and what was rejected? receive mutually compatible answers depends on the reader reconstructing the same distinctions four times independently.

A persistent derived memory is the hypothesis that storing some interpretation is worth its cost. Note what the hypothesis does not say. It does not say retrieval is weak — Chapter 3 forbids that reading. It does not say every interpretation should be stored — query-relative judgements belong to the query, as the three-layers section shows. It says that some interpretations are stable enough across queries to earn storage, and that the book should measure whether that storage pays.

Make understanding persistent

The architecture under test keeps two stores with different epistemic status:

    flowchart TD
    SRC[original sources] --> RAG[conventional RAG]
    SRC --> IDX[GraphRAG indexing]
    IDX --> DER[derived graph]
    RAG --> READER[reader]
    DER --> READER
    READER --> ANS[answer]
  

Raw sources are canonical. The derived graph is a hypothesis about history, not a rewrite of it. If the graph is wrong, the repair is to fix or rebuild the derived state — never to edit the source, which remains the ground the system falls back to and the auditor inspects. That invariant, lossless history underneath and constructive memory above it, governs every later chapter: association traverses the graph but cites the sources, routing chooses graph modes but keeps raw retrieval available, evidence lineage treats derivation as something to verify rather than trust.

Derived memory is a hypothesis about history, not a rewrite of history.

The comparison this chapter runs is therefore:

source history
    ↓
retrieval → context → reader interprets evidence for this query → answer

against:

source history
    ↓
AI interpretation during indexing
    ↓
persistent derived structure (entities, relationships, claims, communities)
    ↓
query over raw + derived state → answer

Same corpus, same reader model, same final context budget. The only difference is whether a prior act of machine interpretation survives between queries.

Raw evidence and derived state

Three layers need distinct names because they fail differently:

Layer 1 — raw source. What actually existed: a session transcript, a commit entry, a decision record, a benchmark note. Layer 1 is authoritative. It can be incomplete or misleading as a record, but it is not the system’s opinion about anything.

Layer 2 — persistent derived interpretation. What the indexing system inferred: this span mentions PostgreSQL; PostgreSQL replaced SQLite here; these entities belong to one community; this claim is supported by those units. Layer 2 is reusable and versioned. It is also where extraction errors live permanently until rebuilt.

Layer 3 — query-relative use. What matters for the current question. The same artifact is decision evidence for what did we decide?, historical background for what runs in production now?, and irrelevant for the caching question. Layer 3 is computed per query and must not be stored as permanent truth, or one question’s framing becomes every later question’s prejudice.

A deliberate terminological boundary follows, and Chapter 7 will enforce it. Layer 2 records derivation provenance: this graph object came from those text units in those artifacts. It does not record evidential support: whether those sources actually license the eventual claim. A relationship row reading PostgreSQL → SQLite is a stored assertion about what the extractor inferred, not a support edge. Graph connectivity must never be read as truth, and a source mapping must never be cited as justification. Chapter 4 answers where did this derived representation come from?; Chapter 7 answers why does that evidence license this claim?

Why a graph?

Persistent interpretation could take many forms: summaries, timelines, tables, embeddings with metadata. The graph form earns its place through three properties, stated here as established background from the survey literature (Peng et al., ACM TOIS 2025; Zhang et al., preprint 2025), not as findings of this book.

First, project history is relational. Decisions supersede proposals, incidents motivate migrations, benchmarks replicate one another, runbooks echo decisions. A flat list of passages stores these connections nowhere; a graph stores them as first-class objects with descriptions and weights.

Second, relations compose across artifacts. No single passage states the contention observed in session-014, confirmed by the benchmark in session-019, caused the importer failure in incident-021, which motivated the decision in adr-007. That chain spans four artifacts. Relationships plus communities give the system somewhere to put multi-hop structure that no chunk contains whole.

Third, communities summarise at scale. When the corpus grows beyond any context window, per-passage retrieval degrades into sampling; community reports offer precomputed corpus-wide summaries organised by topic rather than by file. Whether that helps on real questions is exactly what the Global condition tests.

The estimator of these benefits must be stated alongside the mechanism, because the book’s later verdict depends on it: every benefit above is purchased with LLM inference at index time, stored state to maintain, and a new class of persistent error.

Build it with GraphRAG

The implementation is Microsoft GraphRAG, pinned at version 3.1.2, behind a backend abstraction the book owns. The abstraction matters more than the package: memory is defined here as persistent AI-derived structured understanding, and GraphRAG is the experimental implementation. A later system — incremental, lighter, hand-built — replaces the backend, not the book’s definition.

class StructuredMemoryBackend(Protocol):
    def index(self, force: bool = False) -> IndexReport: ...
    def query_basic(self, question: str) -> GraphQueryResult: ...
    def query_local(self, question: str) -> GraphQueryResult: ...
    def query_global(self, question: str) -> GraphQueryResult: ...
    def query_drift(self, question: str) -> GraphQueryResult: ...
    def query(self, question: str, mode: str) -> GraphQueryResult: ...
    def snapshot(self) -> GraphSnapshot: ...
    def manifest(self) -> dict: ...

Book result. The StructuredMemoryBackend protocol in solution/graph_memory/graphrag_backend/backend.py exists with Microsoft GraphRAG 3.1.2 as its first implementation. All callers — the experiment adapter, the CLI, the health checks, the Chapter 5 adapter — program against the protocol.

What the package contributes, verified against the installed version rather than marketing text: documents, text units, entities, relationships, optional claim covariates, Leiden-hierarchy communities, community reports, and embeddings, persisted as a parquet index. Four query modes ship in the package: Basic (vector search over text units, the closest internal analogue of conventional retrieval), Local (entity-centred search combining graph neighbourhoods, text units, and community context), Global (map/reduce synthesis over community reports), and DRIFT (a primer over community reports followed by iterative local follow-ups). The chapter describes only modes actually exercised; DRIFT’s experimental status is reported honestly below.

Source handling preserves context the interpretation depends on. A statement such as PostgreSQL is the right choice means something different in a chat proposal, an assistant reply, a decision record, a benchmark note, a commit message, and a database export. The source adapters in solution/graph_memory/sources/ normalise every input into a shared envelope — artifact identifier, source type, path, timestamp, actors where stated, content, hash, metadata — reusing Chapter 3’s source identity rather than inventing competing identifiers. Source type affects what kind of historical object the system possesses; it does not make the content correct. That principle is load-bearing: nothing in the pipeline treats decision records as true by virtue of being decision records.

Provenance mapping walks every derived object back toward canonical artifacts through text units and input documents. Anything unreachable is recorded as an orphan with its broken link named, usable as a hypothesis but never as evidence. Health checks report counts, mapping coverage, near-duplicate entities, indexing failures, and build freshness — structural health, explicitly not semantic correctness. The reader inspects all of it without a model server:

python -m graph_memory.cli index
python -m graph_memory.cli health
python -m graph_memory.cli inspect --counts
python -m graph_memory.cli inspect --entity PostgreSQL
python -m graph_memory.cli query "..." --mode basic
python -m graph_memory.cli query "..." --mode local
python -m graph_memory.cli query "..." --mode global

Look inside the derived memory

Book result. The frozen index over the Chapter 3 fixture corpus (ch3-fixture-v0.1, corpus hash 04aac354) contains 20 documents, 20 text units, 39 entities, 65 relationships, 56 claims, 6 communities, and 5 community reports. Indexing ran 999 seconds of wall time, 55 LLM responses, and roughly 128,000 tokens, using ministral-3:8b for extraction and bge-m3 for embeddings. One community (community 2) has no report: the summariser’s output failed schema validation, recorded in the index report as an extraction failure. Build counts and provenance below are read directly from the committed index, not estimated.

The content is recognisably the project’s history, reorganised. SQLITE (degree 17) and POSTGRESQL (degree 8) anchor the migration; ADR-007, SESSION-044, SESSION-040, and the benchmark entities carry the decision and its evidence. A first community report summarises the event-store migration from SQLite to PostgreSQL through contention and benchmarking; another summarises the Redis rejection. So far, so much like a competent reading of the corpus — which is precisely the point. The graph stores what a good reader would conclude, so that later queries need not conclude it again.

Then the mess, which the chapter shows rather than tidies. Entity resolution failed in at least two places the health check flags. J. LINDQVIST (degree 4) and J. LINQVIST (degree 3) are the same person, split by a one-letter extraction typo — and the typo entity owns three relationships, including J. LINQVIST → REDIS for the Session-040 caching proposal. EVENT-STORE and EVENT STORE are the same system under two spellings, stored as two nodes of different declared kinds. A. NOVAK and A.NOVAK repeat the spacing-split pattern. These are not query-time mistakes that vanish on the next question. They are stored, versioned, queryable mistakes, and every downstream consumer — association in Chapter 5, routing in Chapter 6, lineage in Chapter 7 — inherits them until the index is rebuilt. The chapter’s central failure exhibit is not a wrong answer. It is a wrong node.

Provenance, by contrast, is complete:

Book result. All 166 derived objects (39 entities, 65 relationships, 56 claims, 6 communities) map back to canonical source artifacts. The orphan rate is zero in every kind. Source mapping tells us where each derived object came from; per the Layer 2 boundary, that is derivation provenance, not evidential support.

Health verdict: structurally unhealthy for exactly one reason — the missing community-2 report. The sole indexing failure is named, logged, and preserved rather than repaired silently, because a rebuilt-silent index would break the versioning invariant the next section states.

One source, several questions

The old version of this chapter used the proposal/preference/decision history to argue that flat retrieval discards role and therefore an event schema is required. The stronger baseline overturned the therefore: Chapter 3’s reader distinguishes discussion from decision directly from well-retrieved passages on most of the fixture. The example is retained with its conclusion changed. It now investigates reuse rather than failure.

The canonical history runs Monday to Thursday: session-031 proposes moving the event store to PostgreSQL, session-033 prefers SQLite, adr-007 decides PostgreSQL. Six related questions address the same history:

What did we decide?
Why?
Who proposed the alternative?
What was rejected?
What evidence supported the decision?
What systems are connected to it?

Strong RAG answers each by reconstructing the distinctions fresh: retrieving the three passages, reading headers and status lines, and assigning roles per query. The persistent alternative answers from stored structure: entities for the people and systems, relationships for proposal and supersession, claims for the contention evidence, the community summary for the rationale. The empirical question is whether stored distinctions are more consistent across the six questions than six independent reconstructions — and what happens on the seventh question, where the stored distinctions are wrong.

Cross-query consistency of this form is unmeasured in the current runs; the runner records per-case answers but infers nothing across them, and the chapter labels consistency an explicit pending obligation rather than smuggling agreement across query modes into a metric. The claim it does test is narrower: whether graph-backed conditions answer the individual questions as well as strong RAG, at what cost, and with what new errors.

Basic Search

Basic Search is vector search over the index’s text units followed by the same reader that serves the baseline — the closest internal comparison to conventional retrieval, differing mainly in chunking and in what text the index holds. Expect it to behave most like Chapter 3, and treat any divergence as a fact about the index pipeline rather than about graphs as such.

Local Search

Local Search centres on entities: resolve the question’s entities, gather their neighbourhoods, and combine graph context with text units and community summaries. This is the mode whose design best matches decision and relational questions — what did we decide about X?, which incidents influenced the decision? — because those questions name entities whose stored neighbourhoods should contain the answer’s parts.

Global Search

Global Search never retrieves passages. It maps over community reports and reduces the partial syntheses into an answer. Its natural territory is corpus-wide synthesis — what major architectural themes emerged? — where no single passage is the answer and the work is compression across topics. Judged on exact local lookup (what did adr-007 decide?), it is the wrong tool by construction, and the chapter refuses to score it there as though that were informative. The fair test routes global questions to Global Search and local questions to local modes, then reports each mode on its own territory alongside the baseline everywhere.

DRIFT

DRIFT Search combines a community-report primer with iterative local follow-ups. Its status in this chapter is: unmeasured on the fixture suite. A single diagnostic attempt in the audit runs timed out at the 90-second query budget, and the frozen comparison contains no DRIFT cells. Chapter 6 independently records DRIFT as unmeasured in its routing matrix. The chapter does not estimate DRIFT quality from documentation, does not run a full DRIFT matrix for completeness at prohibitive per-query cost, and leaves DRIFT explicitly pending with the timeout artifact committed. Time and cost are experimental variables, and an unmeasured mode is reported as unmeasured.

The experiment

Book hypothesis (pre-registered). Preserving interpretation as a persistent derived graph will match strong RAG on local decision questions, improve relational and corpus-wide synthesis questions where structure composes across artifacts, keep per-answer provenance mappable to raw sources, and cost substantially more in indexing and query latency. Four verdict types were registered before analysis: (A) persistent structure earns a core role through material relational/global/consistency gains at acceptable cost; (B) strong RAG remains sufficient and graph memory stays optional; (C) structure enables later mechanisms without improving direct QA; (D) persistent derived state is net harmful and graph memory is demoted to experimental. The verdict may combine categories.

The frozen comparison (experiments/benchmark/runs/ch4-20260919T205622Z) runs 14 tasks from ch4-tasks-v0.1 over the Chapter 3 fixture corpus, across seven families — locate, decision, provenance, temporal, use, relational, global — with the llama3.1:8b reader shared by all conditions. The graph conditions (Basic, Local, Global) add one GraphRAG query per task and admit the derived synthesis into at most one third of the final context, with raw passages filling the remainder; source-recall scoring covers only directly admitted raw evidence, so derived lineage can never inflate a recall score. Global ran 8 of the 14 tasks; its six missing cells include both global-family and both relational-family tasks — its home territory untested, a coverage defect the analysis does not forgive.

Two fairness qualifications must be stated before any number is read. First, total final context is matched but its composition is not: graph conditions surrender a third of raw budget to the derived block, so their admitted-source recall is structurally disadvantaged relative to the baseline by construction. A recall gap between baseline and graph conditions partly measures that budget split, not retrieval quality. Second, the unsupported-source scorer flags chunk-identifier citations (e.g. incident-021.md:65392e92…) as fabricated while accepting plain source identifiers, which penalises graph conditions differentially for a citation-format difference rather than a grounding difference. Unsupported-source rates are therefore reported but not compared across conditions. Both defects are recorded as instrument obligations: alias lists and citation normalisation need repair before any rerun counts as publication-grade.

What happened

Mechanical scores first, exactly as the frozen artifacts record them (decision exactness over the 9 applicable cases; source recall over all tasks; context tokens estimated; latencies measured wall time):

¹ The baseline cases record component latencies (retrieval plus roughly 5 s generation) rather than end-to-end totals; graph conditions record end-to-end totals including the GraphRAG call. Latency ratios are therefore approximate and, if anything, flatter the graph conditions’ overhead.

Developmental observation. The mechanical decision gaps are dominated by scorer normalisation, not answer quality. Three cells decide the table’s shape: the why-question fixture carries no alias list, so paraphrases of concurrent-write contention (concurrent writes, high write loads) fail while the hyphenated original passes — failing all three graph conditions on answers that state the causal mechanism correctly; the Local Redis answer (rejected the proposal to introduce Redis) misses an alias (rejected the redis proposal) by word order on a substantively correct answer; the baseline’s relational answer names two genuine ledger influences by identifier without stating any mechanism and fails the same way.

Adjudicated rescoring under one stated rule — rescue only cells whose answers contain the expected mechanism in paraphrase the alias list omits, or near-verbatim word-order variants; no rescue for vague or mechanism-free answers — gives best 8/9, Basic 9/9, Local 8/9, Global 4/5 on its covered tasks. The adjudication is committed alongside the frozen run as analysis, not as a modification of frozen data. The largest gap between any two full-coverage conditions is one case in nine. That is noise, not victory, in any direction.

Per-family detail sharpens the picture without changing it. Temporal questions (3/3 recall everywhere, all current/historical answers correct) and the stale-summary trap are solved by every condition — the baseline’s reader handles supersession from raw passages, and nothing in the graph improves or degrades it. The relational case the baseline misses thinly (q-rel-influences) is answered with explicit mechanism by both Basic and Local — the run’s one genuine point for stored structure composing across artifacts. The synthesis case Local misses (q-global-reliability) is genuinely vaguer than the baseline’s answer, naming performance issues without contention, benchmark, or incident specifics. Global mode’s synthesis territory went untested by design of the missing cells, not by verdict of the scores.

Graph structure is not automatically better retrieval

The honest summary of the local workload: strong conventional RAG is extremely difficult to beat, and the graph conditions do not beat it. After adjudication, every full-coverage condition answers eight or nine of nine decision cases correctly. The baseline does this with the smallest context (580 estimated tokens), the lowest latency, no indexing phase, and no stored state to maintain or correct. Basic matches the baseline’s quality at roughly 2.3× the context and 7× the latency plus a 999-second index build. Local costs roughly 12× the latency for one genuine miss more. Global costs roughly 25× with incomplete coverage.

This is a good result, not a failed experiment. It is the result the book’s discipline demands: the rival was built strong, the comparison was fair on the reader and the budget, and the new mechanism was not permitted to win by facing a weakened opponent or by hiding its costs. A chapter that had forced GraphRAG to win here would have taught less than this one does.

Where structure may still help

Three places remain open, each narrower than a general quality claim.

First, the relational case above: composing influences across five artifacts is the shape of question stored relationships exist for, and both graph conditions gave the mechanism explicitly where the baseline named identifiers. One case proves nothing; a relational family with ledger-derived scoring would prove something, and building it is a recorded obligation.

Second, corpus-wide synthesis is untested, not refuted. Global Search ran none of the synthesis questions. Its value proposition — precomputed community summaries when no passage is the answer — cannot be evaluated on a fixture whose questions a six-passage reader already answers. The small global-query family the design calls for does not exist yet; the chapter specifies it (a handful of theme-level questions, ledger-derived where possible, frozen-judge multi-dimensional scoring where synthesis requires judgement) rather than pretending the current suite covers it.

Third, downstream consumption is real and already committed. Chapter 5’s propagation runs over the derived graph through the snapshot adapter; Chapter 7 maps derived graph artifacts into lineage; Chapter 6 routes to graph modes selectively. None of that is evidence that the graph answers questions better. It is evidence that persistent structure has option value — a distinct claim the verdict separates explicitly.

Persistent mistakes

Book result. Persistent understanding creates reusable intelligence and reusable mistakes. The frozen index exhibits both: complete source mapping alongside a one-letter person split (J. LINDQVIST / J. LINQVIST, the typo entity owning three relationships), a spelling-split system (EVENT-STORE / EVENT STORE as distinct nodes of different kinds), and a spacing-split participant (A. NOVAK / A.NOVAK). A reader’s misreading disappears with the query; these misreadings are stored state, inherited by every later mechanism until a rebuild corrects them.

Three properties make stored errors structurally different from transient ones. They are silent: nothing in a later answer marks which parts came from a typo node. They are load-bearing: association, routing, and lineage all consume the graph as ground. And they are expensive to fix: correction means re-extraction and community rebuild, not a better prompt. The missing community-2 report is the same lesson in miniature — a generation failure persisted as structural absence, detected only because the health check names it.

The mitigation the architecture actually implements is boundary, not prevention. Raw sources stay canonical and reachable, so any derived claim can be re-derived or distrusted; provenance mapping exposes orphans before they are used as evidence; version metadata (corpus hash, package version, models, prompts, chunking, community settings, timestamp, code commit) identifies each derived build so errors attach to versions rather than to history itself. What the architecture does not implement is verification of derived content — that is Chapter 7’s work, and this chapter’s errors are its motivating exhibits.

Keep the original history

The rebuild rule follows from the epistemic status: source corpus canonical, derived graph rebuildable, versions explicit. Changing the GraphRAG version, prompts, extraction model, embedding model, or source corpus creates a new derived-memory version; experimental state is never silently overwritten. The current backend records corpus version and hash, package version, chat and embedding models, chunking, community level, claim-extraction settings, and prompt hashes in every run manifest. Incremental update — what must be rebuilt when history grows, what happens to communities and provenance, what the version identity becomes — is documented as a requirement the current backend meets only by full rebuild, with LightRAG’s incremental union design (Guo et al., EMNLP Findings 2025) recorded as the contrast that makes the cost visible. Update economics, not update machinery, is this chapter’s finding.

Fallback runs downward through cost: graph-derived memory, uncertain or insufficient, falls back to strong Chapter 3 retrieval over raw sources. Chapter 6 will show derived mechanisms adding harm on some tasks; the fallback is what makes that finding survivable rather than fatal.

What did GraphRAG actually buy us?

Costs, measured where measurable, estimated nowhere. Index build: 999 seconds wall, 55 LLM responses, roughly 128,000 tokens for 20 small documents — indexing amortises only over query volumes this fixture never approaches. Query latency: Basic ~51 s, Local ~93 s, Global ~196 s mean with a 585 s maximum, against a baseline reader-side cost near 7 s. Context: 2.2–2.6× the baseline’s tokens for equal-or-indistinguishable decision quality. Storage: a full parquet index plus embedding stores for edge lists a flat file could hold. Model calls per graph query: uncounted by the package’s public API and recorded as unavailable, not estimated.

Against that price, measured gains on direct question answering are zero in general: adjudicated decision accuracy is indistinguishable across full-coverage conditions, temporal handling is solved everywhere, and the one relational bright spot is a single case. Genuine option value exists downstream — traversal, selective routing, lineage mapping all consume the graph — but architectural reuse is not empirical quality, and the chapter does not convert it into a score.

Did persistent understanding earn its place?

Developmental verdict: Type C with a Type B core. On direct question answering over the current local workload, strong RAG remains sufficient and the graph adds quality nothing at substantial cost (Type B). The graph nevertheless supplies a persistent substrate — entities, relationships, claims, communities with complete source mapping — that associative retrieval, selective routing, and evidence lineage genuinely consume (Type C). No evidence supports Type A (core-role quality win) or Type D (net harm warranting demotion); Local’s vague synthesis answer and the stored entity errors are costs, not disqualifiers, contained by fallback and rebuild. The verdict upgrades to a book result when the recorded obligations are met: repaired scorer normalisation, a relational question family, a tested synthesis family, and cross-query consistency measurement.

The principle that survives any single package:

The transition from retrieval to memory is not the moment a language model first understands the past. It is the moment some interpretation of that past becomes persistent state capable of influencing future remembering.

Whether preserving that interpretation is worth what it costs is then an empirical question per workload — asked here, answered conditionally, and re-asked by every later layer that inherits the graph.

The next question

A graph is static. Its relationships sit until a query arrives, and retrieval over them — even entity-centred, even community-aware — is still lookup: compare the question against stored items and return the nearest. But remembering, in the systems this book takes as hypotheses rather than models, does something else. A cue touches one memory, activation moves along relations, and the needed memory arrives three steps later by a route no similarity computation planned. The map exists now, with its virtues and its typo nodes. The next chapter asks how recall should move through it — and whether moving buys anything that lookup, however well built, cannot.

References

• From Local to Global: A Graph RAG Approach to Query-Focused Summarization — Edge et al., arXiv 2024. The entities, relationships, communities, and local/global query design implemented here; evaluated by its authors with model-judged comprehensiveness and diversity on query-focused summarisation.
• Introducing DRIFT Search — Microsoft Research, 2024. Primer-plus-follow-up traversal over the same index; reported win rates are vendor-reported and treated as such.
• LazyGraphRAG: Setting a new standard for quality and cost — Edge, Trinh and Larson, Microsoft Research, 2024. Query-time co-occurrence graphs at vector-RAG indexing cost; the lazy-derivation null hypothesis against this chapter’s persistence claim. All figures vendor-reported.
• LightRAG: Simple and Fast Retrieval-Augmented Generation — Guo et al., Findings of EMNLP 2025. Dual-level retrieval with incremental graph updates; source of the community-rebuild cost critique.
• From RAG to Memory: Non-Parametric Continual Learning for Large Language Models — Gutiérrez et al., ICML 2025. Open triples with passage nodes and PageRank retrieval; the closest prior framing of retrieval becoming memory.
• Towards Effective Extraction and Evaluation of Factual Claims (Claimify) — Metropolitansky and Larson, ACL 2025. Claim extraction with ambiguity abstention; its entailment and decontextualisation criteria inform the chapter’s treatment of derived claims.
• VeriTrail: Closed-Domain Hallucination Detection with Traceability — Metropolitansky and Larson, arXiv 2025. Reverse verification over multi-step generative processes; the audit-trail pattern this chapter’s provenance mapping grows toward.
• BenchmarkQED: Automated benchmarking of RAG systems — Microsoft Research, 2025. Local/global query classes and repeated-trial judging; measurement ideas borrowed, instrument not replaced. Vendor-reported.
• Graph Retrieval-Augmented Generation: A Survey — Peng et al., ACM TOIS 2025. Indexing/retrieval/generation workflow formalisation used for the design exposition.
• A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models — Zhang et al., arXiv 2025. Knowledge-carrier versus index versus hybrid taxonomy clarifying what kind of system the implementation is.
• Lost in the Middle: How Language Models Use Long Contexts — Liu et al., TACL 2024. Position-dependent context use motivating ordering controls; no effect size transferred.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis et al., NeurIPS 2020. Origin of generation with retrieval.