notes on a second brain that doesn't lie to itself

I built a personal knowledge base, and the clearest sign it works is that it has already forgotten how it was built.

jwiki is a wiki that reads and writes itself around my work. Every AI coding session I run feeds it; every session I start is briefed by it. It has been running for about six months. In that time it has thrown away almost all of the raw conversations that shaped it, because it had already taken what mattered and had no use for the rest. The record survived. The transcripts didn’t. That was the design.

the problem

The problem it solves is dull and expensive: hard-won context evaporates. You spend an afternoon with an AI working out why a build only fails on one machine, you close the session, and the reasoning is gone. Next week you pay for it again.

The obvious fix is a wiki. I had one. Wikis leak, because capture depends on stopping mid-thought to write things down, and you never do. The good stuff stays in your head or in a dead transcript. Worse, I work across several machines, so whatever did get written drifted out of sync between them.

What I wanted was a memory that maintained itself: something that watched the work, kept the parts worth keeping, and handed them back to me the next time they were relevant, without my having to remember to file anything.

why the obvious fix rots

The tempting version of self-maintaining memory is fully automatic: let the AI write down what it learns into its own store, and read from it later. Several tools do exactly this. At small scale it looks like magic. At any serious scale it rots, in three ways.

The worst is citogenesis. If the memory is injected into every new session, a single wrong entry becomes a briefing note. The next session reads it, acts on it, and restates it in its own transcript as though it were established fact. That transcript is then compiled back into memory as fresh confirmation. The error has now cited itself into truth, and nothing in the loop is capable of doubting it.

The other two are quieter. Retrieval dilutes: the more the machine writes, the more of its own noise it has to read past to find the signal. And contradictions accumulate, because a machine that only ever appends can’t retire anything. A curator replaces a stale fact; a compiler just adds another one next to it.

graduated autonomy

jwiki’s answer is to keep the automation and take away its authority.

Every entry carries a trust label in its metadata: verified or auto. The machine may only ever write auto. Only I can promote something to verified, and here is the rule the whole design turns on: verified entries are immutable to the machine. If a compile pass wants to change something I’ve verified, it can’t; the proposed change is diverted to a review queue I look at later, and the canonical entry is left untouched. That single constraint is the circuit-breaker for citogenesis. The error can propose itself all it likes; it cannot launder itself into canon.

The promotions themselves aren’t a matter of the model’s judgement. They pass deterministic gates: valid schema, a well-formed filename, links that actually resolve, and a rule that overlapping knowledge must merge into the existing entry rather than spawn a duplicate. Anything that fails a gate, or that touches verified canon, becomes a review proposal instead of a write.

What I’m left with is audit-by-exception. Once a week a digest tells me what the machine promoted, what’s waiting for me, and what it spent. I skim it, correct the occasional thing, and move on. Minutes, not hours, and the effort doesn’t grow with the size of the wiki. Canon hardens through use rather than being gate-kept up front.

what six months taught me

Running it in anger taught me more than designing it did. Two examples.

The first was a sync war. The pipeline kept a single state file that held both each machine’s fast, frequent writes and its shared bookkeeping. The two fought: routine writes on one machine collided with the shared record on another, git rebases failed, and unpushed commits piled up until the machines had drifted for weeks. The fix was to split the per-machine state out of the shared file, and let the append-only logs merge instead of conflict.

The second was subtler. The nightly compile kept dying in the cloud, killed by a resource limit with no useful error attached. I only caught it because I’d earlier taught the cost ledger to capture the text of each failure, so the underlying error was sitting there in the log. The lesson stuck: log what broke, not just that something did.

what’s next

Everything so far treats knowledge as exhaust, the useful residue of doing something else. The next step treats it as a product in its own right.

I’ve designed, though not yet built, a research lane: point it at the things I’ve saved to read, let it propose a handful of topics to dig into, and have it produce properly cited, provenance-first entries. Real research rather than session leftovers. It rides on exactly the same trust machinery. A finding is still just an auto entry until I’ve read it and decided it’s verified. The engine doesn’t change; only what I feed it does.

Which is the honest answer to the question this whole site is named after. What’s next is usually a better version of the last thing. Must do better.