Distillation: making knowledge appreciate

The series so far: sessions create knowledge with real replacement cost, and by default it dies at session end (Part 1). Capture has to happen at the point of creation, ambiently and liberally (Part 2). Retrieval has to happen at the point of need, pushed rather than pulled, so every session starts warm (Part 3).

Part 3 ended on the plateau: a reservoir that only ever fills, degrades. This final part is about the missing metabolic function - the scheduled work that keeps captured knowledge true, findable, and improving. Without it, everything built in Parts 2 and 3 slowly turns into the thing it was meant to replace.

How reservoirs rot

You've seen a knowledge base die. The failure modes are distinct and need distinct fixes:

Staleness. A learning was true when captured and silently stopped being true. The vendor fixed the API. The rate limit changed. The constraint that shaped a decision no longer exists - but the decision's rationale still cites it, and retrieval still serves it with a straight face. Nothing in a store-and-search architecture ever re-examines a fact. Truth has a shelf life; storage doesn't know that.

Contradiction. The March learning says the vendor's API can't handle partial updates - the exact constraint from Part 1's inventory. The July learning, captured after the vendor shipped v2, says it can. Both are in the corpus. Both are honestly captured, correctly timestamped - and search serves whichever matches the query phrasing better. The corpus doesn't contain wrong knowledge so much as unreconciled knowledge, which is worse: it's wrong with citations.

Noise. Part 2 told you to over-capture, and it was right - write-time filtering discards the wrong things. But the bill arrives here. Ten raw learnings about the same flaky endpoint, ninety session handover notes for a project that shipped, dead ends for approaches that no longer exist. Each entry was individually worth capturing; collectively they bury the signal and bloat every context pack that draws on them.

Notice that none of these is a capture failure or a retrieval failure. Capture did its job; retrieval did its job. The rot is a maintenance failure - and maintenance is precisely the step that "store and search" architectures don't have. A wiki is a reservoir with no metabolism. That's the whole autopsy.

Distillation: the scheduled metabolism

The fix is a standing process that periodically re-processes the raw material: reviewing what came in, reconciling it against what was already there, compressing the redundant, flagging the stale, and promoting the durable. Call it distillation.

The load-bearing word is scheduled. Curation-when-someone-gets-around-to-it never happens, for the same reason "write it up later" never happens. Distillation has to be a recurring job, not a virtue.

And the reason it's newly feasible is the same reason the leak got worse: the sessions doing the work are now instrumentable, and models are good at exactly this kind of processing - summarization, comparison, contradiction-spotting - over bounded inputs. The knowledge base can afford a metabolism because the metabolic work no longer requires human hours.

Time is the organizing dimension

Distillation becomes tractable the moment your knowledge base can answer time-scoped questions. Not "what do we know about X" but "what did we learn about X between these dates" - and "what entered the corpus this week," "what was last confirmed before March," "what changed in this area since the last review."

We recently added exactly this to Brain: deterministic updated-at windows over the corpus, exposed to agents over the same interface they already browse it with. Not time-scoped ranking - semantic search has no time dimension to speak of - but time-scoped enumeration: give me everything that changed between these two instants, in order, with a stable window I can page through.

That distinction turns out not to cost anything, because distillation never wanted ranking. It converts the work from an archaeology project into a set of small, schedulable jobs:

The automated retrospective. "What did we learn this week?" used to mean someone scrolling history and reconstructing. As a windowed query, it's a bounded input a model can process in one pass: cluster the week's learnings, compress the redundant, write the digest. The weekly review - the ritual every team intends to run and abandons by week six - becomes a job that runs whether or not anyone remembers it.

The backlog that writes itself. Patterns invisible in any single session become obvious across a time window. The same endpoint generated failure learnings four times this month. Three sessions independently rediscovered the same workaround. Two decisions in the same quarter re-litigated the same question. Each of these is an improvement possibility that no one had to notice - the time-scoped scan surfaces it. Recurring pain, queried directly, is a prioritized backlog.

Drift detection. Contradiction-finding is brutal as a whole-corpus problem and tractable as a windowed one: take what arrived recently, check it against standing knowledge on the same subjects, flag the conflicts for reconciliation. The March-vs-July problem gets caught in July - at the moment the newer learning lands - instead of in November when retrieval serves the wrong one to a session that acts on it.

Aging and reconfirmation. Time-of-capture lets facts carry an effective shelf life. A learning about an external system that hasn't been confirmed in a year isn't deleted - it's demoted: retrieval can serve it with its age attached ("true as of last August, unverified since"), and the distillation pass can queue the cheap re-checks. Trust becomes a function of recency, which is what it always actually was.

An honest note from our own reports

This part of the series is also a self-correction, and it's worth being specific about it.

Brain has long had a self-improvement pass - a report on the state of the corpus - and it does catch contradictions, but only within arm's reach. Near-duplicate passages get adjudicated: two entries close enough in wording are compared and one can be ruled to supersede the other, retiring it. That works, and it's more than a plain store-and-search system does.

The gap is what falls outside that radius. Detection was bounded to passages that already look alike, plus additive gap-finding - noticing where the corpus was thin or missing. A fact contradicted in dissimilar words is never compared to the thing it contradicts, so it goes undetected indefinitely. The corpus could tell you where it was ignorant, and where it was redundantly wrong; it couldn't tell you where it was wrong in a fresh sentence. Which leaves the most dangerous rot mode - confidently serving superseded knowledge - substantially unwatched.

Time-scoped enumeration is the answer to our own gap, and it attacks it from a different angle than similarity does: instead of asking "what looks like this fact," ask "what arrived recently about this subject," then compare that bounded set against standing knowledge regardless of how it's phrased. I'd generalize the lesson: audit your knowledge system for which rot modes its maintenance can actually detect. Similarity-bounded checking and additive gap-finding both feel like health monitoring while missing the failure that costs the most.

Spaced repetition for an organization

Individual learners have known for a century that retention isn't a storage problem - material must be revisited on a schedule, with the interval tuned to how it holds up, or it fades regardless of how well it was recorded the first time.

Distillation is the same principle at the level of an organization's knowledge. Capture is the first exposure. Scheduled review is the repetition. Facts that keep getting confirmed get promoted into stable, compressed, front-page knowledge - which is the layer a Part 3 context pack should be drawing on. Facts that age without confirmation decay in trust until re-checked. The corpus doesn't just persist; it consolidates, the way memory is supposed to.

And this is what finally makes the asset language literal rather than motivational. An asset that's maintained appreciates. Capture alone gives you a pile that depreciates from the moment of storage. Capture plus retrieval gives you a useful pile that's quietly going stale. All three, on a schedule, give you a knowledge base whose quality - density, trustworthiness, retrieval precision - is higher this quarter than last quarter. That's appreciation, mechanically.

The loop, closed

The full cycle, assembled across four parts:

Capture at the point of creation, liberally, with timestamps and provenance. Retrieve at the point of need, pushed into every session start so nothing begins cold. Distill on a schedule - digest the recent, surface the patterns, reconcile the contradictions, age the unconfirmed. And feed the distilled layer back into what gets captured and served next, so each pass around the loop sharpens the others.

Part 1 opened with the small layoff - the knowledge that walks out the door every time a session ends, unrecorded, unmourned, written off by default. Nothing in this series required exotic technology to fix that: an instrumentable medium where the work already happens, a store that respects time, and a scheduled process that does what good operators always did with hard-won knowledge - review it, reconcile it, keep it sharp.

The sessions are already running. The knowledge is already being created, today, at whatever rate your team and your agents work. The only open question is the one a balance sheet would ask: are you accruing it, or writing it off?

This concludes the series. Parts 1-4: the leak, capture, retrieval, distillation.