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.

![A tank filled to the brim with shards, nearly all of them dulled to grey; a handful have been reduced to hollow amber outlines, two solid amber shards sit facing each other across a jagged break, and more shards keep dropping in from above.](/assets/blog/p4-reservoir-rot.webp)

## 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:

![A long timeline of scattered grey shards with an amber bracket enclosing one span; the shards inside it are lit, and thin lines descend from the window into three large clean cubes below, while two shards fade out on the way down.](/assets/blog/p4-time-window.webp)

**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.

![Three cubes on a ring joined by amber arrows that run in one direction, the lowest of them amber-outlined, with a dense block of amber shards compounding at the centre inside faint rings.](/assets/blog/p4-loop-closed.webp)

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](/blog/every-session-ends-with-a-small-layoff),
[capture](/blog/capture-stopping-the-leak),
[retrieval](/blog/retrieval-starting-warm),
distillation.*