Where: Kai’s own memory pipeline, across the retrieval, build-statistics and fix-review paths. In production for every customer.
Symptom: none, again. Nothing was broken, nothing alarmed, no customer complained. We only looked because we were about to build something large.
What prompted it
Himanshu asked what would happen if a customer’s operations team asked Kai an ordinary operational question, such as “what’s the flow for confirming a consultation, how long before, and over which channel?” He expected Kai to answer from its own brain rather than by dispatching an engineer to read the repository. Answering that honestly meant reading the retrieval path instead of recalling it.
What we found first: a real failure, and the second occurrence
Kai’s seeded brain on that customer’s box was empty. Measured read-only, the tracking table held 57 documents, and the retrieval index held none of them. The console reported “57 files indexed” because the Brain Map reads the tracking table, not the retrieval index.
That is the identical desync found and remediated two weeks earlier. It came back, silently, and nothing detected it in twelve days. There is still no consistency check between the two tables, the same five-line query we said was worth writing last time.
What we found second: the actual subject of this entry
Setting out to design a freshness system, we went looking for what we would have to build. What we found was three things already being produced and discarded:
- A freshness timestamp on every chunk. A recent change put a source-freshness timestamp on every indexed chunk, and the insert path defaults it so no write site can omit it. A search for the field name across the retrieval code returns nothing. Written by everything, read by nothing.
- The fix review. Kai reviews every shipped fix and writes a summary, a verdict, reasoning, a confidence and structured residual gaps. A search for those fields across the memory code returns nothing. We generate a dated, structured change summary for every change we ship, and none of it reaches the brain.
- The daily commit delta. A scanner keeps an incremental watermark whose own comment describes exactly the catch-up-then-daily-delta behaviour we were about to design. The walker runs, the classifier separates DouJou-authored from human and feature from noise, and then the whole delta is collapsed into a single total for a KPI band. We read and classify every commit, every day, and keep only the count.
- Time hidden: months for the freshness timestamp. The fix review since it shipped at the end of August. The commit delta since a KPI band replaced a hardcoded constant. None of it was hidden, exactly: all three are documented in their own source. Nobody had asked what else they were good for.
- What it cost: nothing yet, and that is the point. What it would have cost is the interesting number. The first draft of the freshness spec proposed a new anchor-diffing subsystem: a schema for provenance anchors, a scheduled sweep to compare them, and a re-derivation path. Then Himanshu made two observations: freshness should be pushed at write time when a feature changes, and a daily pass over the git log would catch whatever bypassed the workflow. Both turned out to be mostly assembly rather than construction. The sweep disappeared entirely, because if a daily pass already reads every commit, it already knows every file that changed, so stale detection falls out of the same pass that writes new memories. One mechanism instead of two.
The genuinely new requirement that survived is one field. The facts store has no topic key and retrieval has no recency weighting, so appending memories about one feature would have produced five contradictory chunks instead of a history. That, not the sweep and not the anchors, is the load-bearing piece, and we would have found it late.
Why nobody noticed
Each of the three was built for a specific, narrow purpose and did that job correctly. The timestamp was for provenance display. The fix review was for the ship gate. The commit delta was for a KPI band. Every one of them shipped, worked, and was reviewed as itself. No step in our process asks “what else is this output good for?”, and a field that is written but never read raises no test failure, no type error and no alarm. A capability with no consumer is indistinguishable from an absent capability, from the outside.
The lesson, the inverse of the usual one
Elsewhere in this diary the pattern is a workaround outliving the constraint that justified it. This is the mirror image: a capability outliving our awareness that we have it. Both are drift between the system and the written record. The difference is only which side is ahead. The second kind is more expensive, because it is invisible in exactly the moment you are about to spend money re-creating it. The design review for a new subsystem is precisely when nobody is inventorying what already exists.
The cheapest countermeasure, and the one we are adopting: before specifying anything that produces or consumes derived knowledge, search for whether we already produce it. Two of the three above were found by a single search for a field name, in under a minute each. That check now belongs in the spec-writing process, not in the review that follows it.
What we did about it
The freshness specification was rewritten around three writers instead of one sweep: change events from the build and serve paths, a daily repository delta for everything that bypasses the workflow, and an ask-time promotion. Its first phase is the consistency check that this entry’s first half has now needed twice. The spec says plainly which parts already exist, so the next reader does not re-derive them a third time.
