Picture the most over-qualified assistant you have ever hired. They have read everything you have ever written. Every email, every document, every decision. And yet, every single time you walk into a meeting with them, they introduce themselves again. They have no memory of yesterday's conversation. They re-read the relevant files on the spot, in front of you, and then offer a confident answer assembled from whatever they managed to skim in the last ten seconds.

That is what most teams have actually built when they put a large language model on top of their own documents. Ask it something on Monday and it searches. Ask it the same shape of question on Tuesday and it searches again — from scratch, as though it had never seen your corpus before. It is a very well-read stranger who re-introduces themselves at every meeting.

This book is about why that happens, and why the fix is none of the things you would reach for first. Not a bigger model. Not a better vector database. Not a cleverer prompt. The fix is a change in when the thinking happens. But before we can move the thinking, we have to look honestly at what the current approach costs — and where it genuinely earns its keep.

What RAG is, and where it is genuinely good

The default pattern is retrieval-augmented generation — RAG. Spelled out, it is mechanical and sensible: chop your documents into chunks, turn each chunk into a vector, and at the moment a question arrives, fetch the handful of chunks that look most similar to the question and hand them to the model to write an answer.

For a whole class of questions, this works beautifully. "Find me the paragraph about the renewal clause." "What did the Q3 report say about churn?" When the answer is a passage that lives in one place and the raw text is what you actually want, vector search is fast, cheap, and good. We should say this plainly, because the rest of the book is a critique, and a critique that pretends RAG is worthless is a critique nobody serious will trust. When the raw data itself is what you need, RAG can perform well.

The trouble starts the moment your questions stop being about a single passage and start being about how things relate.

Failure one: there is no slot for relationships

Vector similarity matches text that looks like your query. That is all it does. It has no representation for "this requirement is defined in document A, constrained by document B, and exceptioned by a clause buried in contract C." The relationship between those three documents is the answer — and the relationship is precisely the thing chunk similarity cannot see.

This is not a fringe complaint. It is the reason Microsoft built GraphRAG in the first place. Their research team states it flatly: baseline RAG "fails on global questions directed at an entire text corpus … since this is inherently a query-focused summarization task, rather than an explicit retrieval task."¹ Elsewhere they put it in plainer words: baseline RAG "struggles to connect the dots … when answering a question requires traversing disparate pieces of information through their shared attributes."²

Chunking makes it worse. Fixed-size splits cut straight through the logic of a document. Microsoft's own architecture guidance warns that fixed-size chunking "isn't recommended for text that requires semantic understanding and precise context," because "relevant context that exists across multiple chunks might not be captured."³ Each chunk becomes an island, divorced from its place in the larger argument. You get half a requirement in one fragment and half in another, and neither makes sense alone.

Name the thing honestly, because we will be fighting it for the rest of the book: the enemy is the query-time discovery model — the unspoken assumption that "make the AI know my domain" means "bolt on a vector store and search it live, on every question."

Failure two: the "retrieve more" reflex backfires

When retrieval misses, the instinct is to retrieve more. Widen the net. Pull the top fifty chunks instead of the top five. Stuff a bigger context window. This is exactly backwards, and the evidence against it is now overwhelming.

The classic study here is "Lost in the Middle": model accuracy is highest when the relevant information sits at the very start or very end of the context and sags when it is buried in between. The NoLiMa benchmark sharpened the point for the long-context era, and Chroma's testing across eighteen frontier models found the same shape everywhere. The conclusion is uncomfortable for anyone whose plan is "use a bigger window": more chunks do not mean better answers. A larger context window is not a substitute for a better-shaped context.

The tax, paid twice

So the query-time discovery model pays a tax, and it pays it twice. First on discovery: many round-trips to assemble one answer, slow and token-heavy⁷⁸. Then on the payload: even when retrieval "succeeds," the bloated stack of chunks it returns actively dilutes the model's attention, by the very mechanism the studies above describe.

Giving an agent search tools — even good ones like RAG — there are a lot of circumstances where discovery is slow, token-bloated, and returns stuff you didn't want. It takes many searches just to understand the relationships.

There is a deeper way to say what is going wrong. RAG retrieves text. It does not retrieve understanding. When you ask a relationship-shaped question, the understanding you need is not sitting in any single chunk waiting to be matched — it has to be assembled by reasoning across documents. Knowing is not the same as retrievable. And when the knowing was never built, no amount of searching at query time can conjure it.

A note on two neighbouring problems, so we can set them aside cleanly. If you have also hit context bloat from the tooling side — a stack of MCP servers eating fifty thousand or more tokens before your agent thinks a single thought⁹ — that is a real problem, but a different one; we have written about why code-first agents beat MCP on context elsewhere. And the idea of a "routing index" that gives an agent information scent before it searches is its own subject, which we cover in our work on Context Engineering and the Cognition Supply Chain. This book is about what happens upstream of retrieval entirely.

That last point is the hinge for everything that follows. The understanding was never built. It is re-derived, badly, under latency pressure, by similarity math that cannot see relationships. So here is the question that opens the next chapter, and the rest of this book: what if we built the understanding before the question instead of after it?

In April 2026, Andrej Karpathy gave a name to something a number of us had been quietly doing for years. He called it the "LLM Wiki," and described it like this: rather than retrieving from raw documents at query time, "the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files," so that "the knowledge is compiled once and then kept current, not re-derived on every query."¹⁰

I had been running a version of this over my own inbox for a couple of years before there was a name for it. When the field's most-watched engineer independently names the thing you have been doing, it is worth stopping to write down precisely why it works. That is this chapter.

Move the work before the question

Recall the diagnosis from the last chapter: RAG re-derives understanding on every question because the understanding was never built. The relationships in your domain are real, but they live nowhere — they get re-inferred, under latency pressure, by similarity math that cannot represent them.

The move is simple to state and consequential to adopt. Do the work off-cycle, once per source, before anyone asks anything — and bake the result into a structure that holds relationships natively. You are not just indexing raw data; you are pre-digesting it into a conceptual worldview. The intelligence gets injected before the user ever asks a thing.¹¹

This is the whole reframe, and it deserves a sentence you can carry around: the index stops being a pointer to the data, and the index becomes the data. Everything else in this book is a consequence of taking that sentence seriously.

The artefact: claims and edges, not chunks

The word "wiki" undersells it, so let us be precise about the artefact, because the precision is the point. A page here is not prose. It is a set of claims — atomic, dated statements — and edges — typed links between them: related, supersedes, a link to [[Project X]]. The claims hold the facts. The edges hold the relationships. And once the relationships live in the structure, the model navigates them instead of re-inferring them from chunk similarity every single time.

Call it the map over the swamp. Language models are superb at navigating structured, interlinked text and clumsy at wading through raw piles of it. Transform the messy inputs into a clean map of claims and edges, and the model gets to do the thing it is good at.

"The index became the data"

Here is the claim in the most concrete terms I can give it, from the project we will meet properly in Part II: the index became the data. Even with full access to read the original email, search the email database, and run a RAG search, the system basically did not need those tools — it answered a high percentage of questions straight from the wiki.

It is worth being careful about attribution here, because precision builds trust. What Karpathy is owed is the clean public framing of the pattern: a persistent wiki, built incrementally, compiled once and kept current. The added emphasis — that the pre-processing is almost as important as the wiki itself — is my own, drawn from years of watching where the value actually accrued. (For the same reason, a much-quoted line about "Markdown and Git as the only source of truth" lives in the comments under Karpathy's note, not in his own text; we will make the ownership argument on firmer ground in Chapter 4.)

One level up: outputs are cheap, the source is the asset

There is a principle underneath all of this that we have written about as Worldview Recursive Compression: frameworks function as source code, while generated outputs are regenerable artefacts derived from that source. Apply it here and the picture snaps into focus. The wiki-graph is the compiled source-code of your corpus, not a cache of it. The raw emails and documents are regenerable raw material. The map is the durable asset. Lose the raw data and you can rebuild the map slowly; lose the map and you are back to being a well-read stranger.

Take the support question from Chapter 1 — "how does our refund policy interact with the enterprise SLA exception for region X?" — and imagine it answered from a wiki-graph instead. There is a Refund Policy page with an edge exception-for → [[Enterprise SLA]] and a region-scope edge to region X. One lookup returns the relationship, intact. Not three disconnected chunks that each mention a piece. The relationship was pre-built, so the answer is already there.

There is one catch the reframe quietly introduces. A map you have to maintain by hand goes stale the day you stop tending it. The whole idea only pays off if the maintenance is automatic — so the next question is the one that defines the rest of Part I: how does the map maintain itself?

A map that maintains itself is the difference between a clever idea and a system you can actually live with. The way you get there is almost suspiciously simple: two agents, given the same toolset and a single shared instruction, doing opposite jobs. One builds. One compacts. The compacting is the part most people skip, and it is the part that does the real work.

This chapter states the engine in the abstract — no inbox, no specific domain — because everything in Parts II and III is this same engine pointed at different corpora. Learn it once here; recognise it everywhere after.

The engine, in one picture

[ New source ]
      |
      v
+--------------------------+    reads current wiki,
|   1. INGESTION AGENT     | -> writes / updates
|        (the builder)     |    claims & edges
+--------------------------+
      |
      |  (page crosses ~12 claims / size threshold)
      v
+--------------------------+    combines, fades stale,
|   2. JANITOR AGENT       | -> converts claims -> edges,
|       (the compactor)    |    spins off new pages
+--------------------------+
      |
      v
[ Leaner, smarter wiki-graph ] -> next source starts from here

Component A — the Ingestion Agent (the builder)

The builder processes inputs one at a time. This constraint matters more than it looks. A single source is small enough to reason about properly; batch ingestion quietly re-introduces the bloat problem we just spent a chapter escaping. The builder reads the current state of the wiki first, then writes — updating an existing claim, drawing a new edge, or spawning a fresh page. It edits the map; it does not append blindly to it.

In practice a single source touches a handful of pages, not the whole graph — Karpathy notes a source "might touch 10–15 wiki pages."¹⁰ That locality is what keeps each ingestion decision high-quality and, crucially, auditable.

Component B — the Janitor Agent (the compactor)

Left alone, an append-only wiki degrades into a text dump — exactly the swamp we were trying to avoid. The Janitor is what prevents entropy. It wakes on page bloat: once a page crosses roughly a dozen claims, or a size threshold, it gets handed over for trimming.

Its jobs: combine redundant claims, fade stale ones, spin clusters into their own pages, and — the load-bearing move — convert flat claims into edges. "Met with X on Tuesday" stops being a standalone claim and becomes an edge to [[Project X]]. The whole intent is to reduce the number of outright claims, so that more of the information is held in the edges, in the connections.

The index didn't just get smaller. It got smarter with every janitorial pass.

This is not an exotic idea. It is the oldest idea in cognition, automated. In the "Generative Agents" research, the agents that stayed coherent over long horizons were the ones that periodically generated reflections — higher-order, abstract memories synthesised from scattered raw observations and stored back in their place. Remove the reflection step and the agents degenerated into repetitive, context-free behaviour.¹³ The Janitor is reflection, running on your corpus. It is what stops the system from drowning in its own notes.

Component C — North Star, not rules

The agents are not governed by a long list of prescriptive instructions. They are governed by a single directive — a North Star. I made the agent prompts less prescriptive and more general, and handed them one guiding intent instead of a rulebook. That choice is doing more work than it appears to.

Why does a heuristic beat hard-coded rules here? Because the decision the Janitor faces on every old claim is genuinely a judgment call: is this noise to delete, or context to abstract into an edge? You cannot write that rule in advance for every case. You can give the agent a clear intent — "act as a personal assistant building a consistent worldview; favour recent information over old" — and let it decide. The index does not just get tidier; it gets wiser about what to keep.

Component D — chronological stacking (decay for free)

Append claims in date order, so the oldest float to the top of the page. That is the entire temporal-decay mechanism. No timestamp-delta arithmetic, no time-to-live fields, no expiry jobs.

By putting the older claims at the top, you have handed the model a timeline view. It reads top to bottom, sees how a thought or a project evolved, and can tell at a glance when an older claim has been superseded by a newer one below it — then distil that history into a compressed, relational form. Decay stops being a calculation and becomes something the agent simply reads.

Watch the four parts move together on a neutral example. A claim is added on day one — "decided to use Postgres." Three more accumulate over the following weeks. The page crosses the threshold, and a Janitor pass folds them into a [[Datastore Decision]] page with an edge superseded-by → [[Move to Aurora]] once a later source arrives. Ingest, accumulate, compact, connect. The raw claims shrink; the relationship survives, sharper than before.

That sharpening is not free, of course. The Janitor burns tokens off-cycle, forever, whether or not anyone asks a question that day. So why is that a better deal than RAG's seductive "free until you ask"? That is the economics — and it is the subject of the next chapter.

Your competitor can buy your model tomorrow. They can subscribe to the same vector database, copy your embeddings, even hire your engineers. What they cannot buy is two years of compaction — the edges your Janitor drew while they were still re-searching raw documents on every question. That is the whole economic argument in one sentence. The rest of this chapter earns it.

Pre-compute once vs. re-search forever

RAG looks free because it does nothing until asked. That is exactly what makes it expensive. The instant a question arrives, it pays the full discovery tax — and it pays that tax again on the next question, and the next, for every user, forever. The cost is real; it is just spread thinly enough across queries that nobody itemises it.

The wiki-graph pays the cost once per source, off-cycle, and turns retrieval into a single cheap parallel lookup. The cost did not vanish. It moved to where it amortises.

The arithmetic favours the map more than the headline number suggests, because the multi-search loop is not a one-off — it recurs on every interaction, while the pre-processing happens once and then sits there as an asset. Frame it as a balance sheet and the contrast is stark: the index is capital; live search is an operating expense that never stops.

RAG looks free because it does nothing until asked — then it pays full price on every question, forever. The index is an asset. Live search is an expense that recurs.

Freshness versus stability — resolved, not traded

Most "auto-updating" knowledge systems make you choose your failure mode. Freeze the index and it goes stale. Let it rewrite itself freely and it churns into chaos. Pick your poison — unless the maintenance itself is intelligent.

We have already built the resolution, in Chapter 3, so there is no need to re-argue it here: chronological stacking keeps freshness legible, and the Janitor keeps stability by compaction. Old claims float up and get folded into an edge — not frozen, not churned. That is why the index improving on each pass is what lets the economics compound rather than decay. A system that got messier with every update would make pre-processing a liability. One that gets leaner and smarter makes it an investment.

Architecture compounds; models do not

A model upgrade is a one-time lift. You move from one version to the next, outputs improve a little, then plateau until the next release. No compounding. Architecture is different: every edge the Janitor draws makes the next retrieval better. The system improves because the map improves, not because the weights changed.

We think the durable asset is the map, not the model. You rent the model; you own the map. This is the same compounding loop we have described as a kernel flywheel — better map leads to better retrieval leads to better outputs leads to patterns worth keeping leads to a richer map. And it is where the moat actually lives. A compacting asset that compounds beats an expense that recurs, every time, on a long enough horizon.

And you own all of it

The artefact is plain markdown. That is not an aesthetic preference; it is the ownership story, and for a business it may be the most important part. A markdown wiki is inspectable by a human, diffable in Git, portable across model providers, and locked inside no vector database. When the AI gets something wrong, you open the file and see why. When the Janitor makes a bad consolidation, you revert the commit.

The wider field is converging on exactly this. Anthropic, writing on context engineering, names "structured note-taking, or agentic memory" — where "the agent regularly writes notes persisted to memory outside of the context window" — as a first-class pattern, and states the trade-off that makes the whole book's case in nine words: "runtime exploration is slower than retrieving pre-computed data."¹⁴ Anthropic now even ships a file-based memory tool so agents can "build up knowledge bases over time … and reference previous learnings without having to keep everything in context."¹⁵ The durable asset is the map; every vector index built on top of it is disposable and rebuildable from the text.

That is the doctrine, the worldview, and the economics. Enough theory. The next two chapters show the whole thing running in the wild — a system I fed one email at a time, for two years, and what it could do by the end.

I gave an AI one job for two years: read one email at a time, read the wiki, update it. Then do it again. Forever.

That is the entire setup. There is no clever trick hiding in it — no proprietary model, no exotic retrieval stack. And yet what it grew into was an assistant that understood what I thought was important, in a way that still slightly surprises me to describe. Part I gave you the pattern in the abstract. This chapter is the pattern lived: the same four components from Chapter 3, running over an inbox, with all the texture the abstract version leaves out.

The North Star that ran it

Everything started with one sentence. I gave it a North Star: it was my personal assistant, and I was building a worldview for that assistant. And one directive about time: favour recent information over old.

I deliberately made the agent prompts less prescriptive and more general. This runs against the instinct, which is to over-specify — to write pages of rules anticipating every situation. The opposite worked better. With a clear North Star, the agent handled the edge cases a rulebook never could have enumerated, because it was reasoning toward an intent rather than matching against a checklist. (We covered why a heuristic beats hard-coded rules in Chapter 3; here you are watching it pay off.)

Ingestion in practice

The builder's loop was exactly the abstract one from Chapter 3, made concrete. One email arrives. The agent reads the current wiki, then decides what to do: add a claim, update an existing one, draw an edge, or spin up a new page. Free to create new pages and new connections whenever the email warranted it.¹⁰

The discipline of one email at a time is what kept the quality high. Each email was a small, bounded decision — the agent was editing the map, not dumping text into it. A claim looked like a dated, atomic line on a page: on a [[Project X]] page, "2024-03-02 — agreed scope cut with vendor." An edge looked like a link folded in later: [[Project X]] —involves→ [[Vendor Y]]. New claims were appended in date order, which — per Chapter 3's fourth component — meant the oldest naturally floated to the top of each page.

The Janitor in practice

Then there was the second agent. Once a page passed about a dozen claims, I handed it to the Janitor with the simplest possible instruction: here is a wiki page that needs trimming. It had the same toolset as the builder and the same North Star — that symmetry, again, was the point.

What it did with that freedom is the part that surprised me. It combined related claims, faded the old ones, spun clusters into their own pages, and converted claims into edges — so that more of the information ended up held in the connections than in standalone statements.¹³ It autonomously decided whether an old claim was irrelevant noise to be deleted, or historical context that needed to be abstracted into a connection. That is a judgment call, made hundreds of times, without my supervision — and the North Star kept it on track.

What made it feel different

By the end it was not storage. Storage is dumb; this was not. It had a model of what I considered relevant and important. I will save the payoff metric for the next chapter, because it deserves its own page — but the texture is worth naming now.

It could truth the data it wanted, and it understood the relationships.

That verb — "truth" as a thing you do to data — is the most honest word I have for it. The system did not just retrieve the right facts; it had a stance on which facts were load-bearing and how they connected. Two years of one-email-at-a-time ingestion, and a Janitor that never stopped consolidating, had compiled a worldview.

The obvious question is what all that quiet work actually bought at the moment I finally asked it something. So let us watch a single retrieval, up close.

Here is the moment two years of compaction paid off. When the retrieval agent went looking for an answer, it requested about half a dozen wiki pages in one parallel call — and it was so accurate that it did not need to follow up with any email searches. It suddenly knew exactly which connections it needed, really quickly. The five-search crawl from Chapter 1 collapsed into a single lookup.

And the part that still lands hardest: even with full access to read the original email, search the email database, and run a RAG search, the agent basically did not need those tools. A high percentage of questions it answered straight from the wiki. The index had become the data. You have, in effect, built a custom semantic caching layer that mirrors long-term human memory consolidation¹³ — the relationships are pre-resolved, so the lookup is trivial.

This is exactly where the wider field has landed, and it is worth letting an outside voice say it. Anthropic, writing on context engineering, names the precise trade-off this whole book rests on, in nine words: "runtime exploration is slower than retrieving pre-computed data."¹⁴ Pre-compute the understanding, and retrieval is cheap. The same write-up elevates "structured note-taking, or agentic memory" to a first-class pattern — the agent writing notes outside the context window and pulling them back later. The industry converged on pre-processing because the alternative does not scale.

One deliberate exclusion: keep the numbers out

There was one counter-intuitive rule that made retrieval sharper, not weaker. I told the agents not to record actual numbers and figures in the wiki. So when I genuinely needed a hard metric, I did have to go back to the email for it — but the wiki knew exactly which source to point at.

This is a feature, not a gap, and the reasoning generalises. Relationships and figures have different failure modes. A stale relationship is usually still directionally true; a stale number is simply a wrong answer. So keep the graph for relationships — the thing it is uniquely good at — and let it route you to the authoritative source for the digit. The graph optimises for worldview; it knows precisely which raw document holds the metric, which means no blind semantic search when precision matters.

This setup essentially mirrors human memory consolidation during sleep — transferring short-term, messy daily logs into long-term, highly efficient relational networks.

That analogy, flagged back in Chapter 3, is the one I keep returning to. The Janitor is doing what a brain does overnight: taking the day's scattered, noisy observations and consolidating them into compact, connected structure. By morning, you do not remember every individual moment — you remember what they meant, and how they fit. That is what a good index becomes.

The honest part

A doctrine that only tells you where it wins is marketing, not engineering. So here is where this approach is not the answer, and where it can bite. This is the reference point the rest of the book returns to whenever the question of limits comes up.

Say the principle plainly, because it is the one that keeps this approach trustworthy: self-maintaining does not mean unsupervised. It means the supervision is cheap and legible. You are not watching every consolidation; you are reviewing a diff when something looks off, and running a lint pass before you trust the map unattended. Pretending the Janitor is risk-free would be the dishonest move — and it would be the move that gets someone burned.

This ran on my inbox. But nothing about the loop is personal. Claims, edges, a builder, a janitor, a North Star — point that engine at a team's codebase, a tender response, or a pile of research papers and the same machine runs. Part III is three such variants.

Every engineering team has a lesson it re-learns every sprint. The auth-token refresh that is more complicated than it looks. The service with the race condition nobody should build on. The rule that you do not deploy at four o'clock on a Friday. Each one gets rediscovered the hard way by whoever did not happen to be in the room the last time it bit.

The memo that would have prevented it does not exist — not because nobody believes in writing things down, but because nobody compacts the learnings into anything durable. The fix is a Janitor that does it for them. This is the first of three variants, and the rule for all three is the same: it is the same engine from Chapter 3, pointed at a new corpus. No new framework — a new domain.

The four components, mapped to a team

You already know the parts, so this is quick (the mechanism lives in Chapter 3; here we only re-aim it):

The Janitor is an automated Learning Extraction Ritual

We have written before about a discipline we call the Learning Extraction Ritual: at the end of every piece of work, capture three things — the sticking points, the surprises, and the never-agains — and feed them into the team's canon. It is a genuinely good practice. It also has one fatal weakness: humans do not do it consistently. Teams embrace it intellectually, add it to the checklist, and weeks later it has quietly fallen away — precisely when they are busiest, which is precisely when the learnings are most valuable.

The doctrine closes that gap. The Janitor runs the ritual automatically. It reads the conversation history, the PR threads, the incident notes, and extracts the invisible learnings into edges — so the ritual sticks without anyone having to find the discipline to perform it. The machine does the part humans reliably skip.

The durable asset is the map, not the memo. A memo nobody compacts is just entropy with good intentions.

Why chunks fail here specifically

Team knowledge is dependency-shaped, the way Chapter 1 described — a decision points to its rationale, which points to the constraint that forced it, which points to the outcome that validated or killed it. A chunk store loses the chain.³ Ask it about the decision and it returns the decision, or the rationale, but not the relationship between them. The edges are exactly what make a decision navigable:

[[Move to Aurora]]
   --because--> [[Postgres write-throughput limit]]
   --validated-by--> [[Q3 load test]]

And because the artefact is markdown in Git, a Janitor consolidation is a reviewable change — a pull request a human approves — not a silent mutation of a black-box store. That review gate is the safety the single-user inbox of Part II never needed, and it is what makes the pattern work for a team rather than a person. The map is the team's Org Brain: owned, audited, and portable across whatever tools each engineer happens to use. (Hybrid and the consolidation risk are covered in Chapter 6; nothing changes here except who clicks approve.)

A team's stakes are velocity — not re-paying for lessons it already bought. Raise the stakes from internal velocity to external accountability — a tender you can lose, an auditor you must satisfy — and the same loop earns its keep in a different currency. That is the next chapter.

Your retrieval returns three paragraphs that mention safety. The evaluator's question was narrower and unforgiving: did the bid address clause 3.2.1(b) — AS/NZS 4801 compliance — with evidence? Mentioning safety is not answering the clause. And that gap, the distance between "retrieved relevant text" and "proved the specific requirement is met," is where tenders are lost and audits go sideways.

This is the second variant, and it is the one where the doctrine's logic is at its most literal. Requirements and evidence are claims and edges. We have proved this in production before; the self-maintaining loop is what makes it durable.

Why chunks fail here, specifically

Chapter 1 made the general case against chunking. Compliance sharpens every edge of it:

• Requirements span clauses. A single requirement can run 800 tokens across nested sub-clauses; fixed-size chunks fragment it, leaving half a requirement in one chunk and half in another.³
• Keyword mismatch. The tender says "WHS"; your proposal says "Work Health & Safety framework." Similarity catches some of that and misses the regulatory synonyms that matter most.
• No requirement-to-evidence mapping. You retrieve similar text but cannot prove it satisfies clause 3.2.1(b). And with no mapping, there is no way to produce a compliance matrix — "127 requirements, 119 addressed, 8 gaps needing input."

The four components, mapped to requirement–evidence

The same engine, re-aimed (mechanism: Chapter 3). Each requirement is parsed as a claim with a stable identifier — RFP_SEC3.2_REQ007. Each proposal capability is evidence. The edges are typed requirement-to-evidence links, forming a bipartite graph: [[REQ007 AS/NZS 4801]] —satisfied-by→ [[Cert: OHS Mgmt System]]. This is the claims-and-edges doctrine in its most auditable possible form. The Janitor keeps the graph current as capabilities and evidence change — superseded certificates faded rather than stranded, unmet requirements surfaced as edgeless nodes. This generalises the compliance-first shaping from our Intelligent RFP work; the loop is the new part.

The self-maintaining angle is the new contribution

Our prior art proved a static graph beats chunks. The doctrine adds the loop, and the loop is what matters in this domain: tenders recur, certificates expire, capabilities evolve. The Janitor keeps the requirement-evidence graph live, so the next bid starts from a current map rather than a fresh re-scrape of last year's documents. A recertification event arrives, and the Janitor invalidates the old evidence edge, links the new certificate, and leaves the requirement satisfied — without a human re-mapping anything.

Traceability is the payoff — not speed

In Part II the headline was a fast lookup. Here the headline is different: every answer traces to a source evidence node, so an auditable compliance matrix falls out for free.² And the numbers-out discipline from Chapter 6 matters doubly in this domain. Keep the exact figures — prices, dates, certificate numbers — at the source; let the graph hold the relationships and route to the authoritative document for the digit. A stale price baked into a graph is a lost tender. A routed price is correct by construction.

Compliance graphs encode what must be true — prescriptive relationships, externally judged. Research is messier: sources disagree, supersede, and contradict each other. Point the same loop at a contested corpus and the Janitor's job changes from compaction to reconciliation. That is the last variant.

Two hundred open tabs and forty papers that all say almost the same thing. Three report a key metric at different values. Two have since been quietly superseded. One contradicts the rest and nobody noticed. Ask your RAG about it and it cheerfully retrieves whichever chunk is most similar to your query — and silently drops the disagreement on the floor.³

This is the third and final variant, and it stretches the doctrine to its limit: a corpus that resists having a single coherent worldview. The same engine still runs, but the Janitor's character changes.

The four components, mapped to a research corpus

The loop is the Chapter 3 loop, re-aimed once more. Ingestion takes sources and papers one at a time and writes claims (findings) and edges (agrees-with, contradicts, supersedes, depends-on). Chronological stacking appends findings by date, so a 2026 result floats above a 2023 one and supersession is legible at a glance. The North Star shifts to fit the domain: "maintain a faithful map of what is known, contested, and superseded; favour newer evidence, but never silently delete a contradiction."

The Janitor's job changes: reconciliation, not just compaction

In the inbox of Part II, the Janitor mostly compacted a single coherent worldview. A research corpus is adversarial, so the Janitor has to do something harder: reconcile. It clusters a contested finding, attaches a supersedes edge to the newer result, and keeps the dissent visible rather than smoothing it away.

This is exactly the "lint" pass Karpathy describes — scanning for "contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links."¹⁰ In the earlier chapters the lint was a safety net (Chapter 6). Here it is the main event. And it has academic pedigree: the reflection pass in "Generative Agents" synthesised higher-order structure from scattered observations¹³ — the research Janitor synthesises the shape of the evidence from scattered findings.

Contradiction-as-edge is the differentiator

A chunk store buries disagreement. Ask it a question and it returns the single most-similar passage, dropping the three that disagree — which means it can be confidently, invisibly wrong.² The graph does the opposite. It makes disagreement a node you can navigate: a [[Contested: Metric M]] cluster with edges to each side and a supersedes link to the current best estimate. You retrieve the state of the debate, not a lucky chunk.

The numbers-out rule from Chapter 6 applies here too, with a research twist. Keep claims directional in the graph; route to the paper for the exact statistic and its confidence interval. A graph that asserts "M = 0.42" is brittle and quietly authoritative about something genuinely uncertain. A graph that says "M is contested; current best estimate per the 2026 study — see source" is both more honest and more useful.

Three domains — a personal worldview, a team's institutional memory, a contested literature — and one engine underneath all of them. The only question left is the one you can answer this fortnight: does it beat your RAG on a question that actually matters to you? That is where we finish.

Pick the one dependency-shaped question your RAG keeps fumbling — the one where it returns three chunks that each mention a piece and none of them answer the relationship.³ You felt that question in Chapter 1, and you have probably had a specific one in mind ever since. Good. We are going to settle it.

The two-week test

This is a sequence, not a calendar. Do not turn it into a four-week project plan; the whole point is that it is small.

The minimal loop — a starter checklist

When you are ready to automate, you are assembling the same four components from Chapter 3, plus two disciplines from Chapter 6. Keep it this short:

• Source intake: one source at a time; read-then-write (edit the map, don't append blindly).
• Claim/edge schema: atomic dated claims; typed edges (related, supersedes, [[Entity]]).
• Janitor trigger: a page-size or roughly twelve-claim threshold; jobs are combine, fade, convert-to-edge, spin-off.
• North Star sentence: one directive encoding purpose plus a recency preference.
• Chronological append: date-ordered, oldest on top — decay for free.
• Keep numbers out of the graph; route to source for hard figures. Add a periodic lint pass before you trust it unattended.¹⁰

What success feels like

If it works the way it worked for me, the change you notice is not "better search results." It is that the system stops re-introducing itself. It starts the next question already knowing your world — because the knowing was compiled in, ahead of time, and kept current by a janitor that never sleeps.¹⁰ The well-read stranger from Chapter 1 finally becomes a colleague.

For a team, this is how you build an Org Brain that compounds — not through model access, and not through a fine-tuning run you cannot inspect, but through a self-maintaining map your team owns, audits, and carries across tools. You rent the model. You own the map. Build the thing that compounds.

RAG searches your data. A self-cleaning wiki-graph already knows it. The difference is just when you decided to think.