When your knowledge base is wrong about itself

Picture yourself in a client meeting. A page in your knowledge base makes exactly the point you need, and underneath it: 3 sources. Someone asks which. You open the list, and there are two.

Nothing here was hallucinated. The prose is right. Every claim carries its citation. Only the number beside it does not.

That is a failure mode a handwritten wiki does not have, and one the whole second-brain conversation skips past. We found it in our own system, and this is how it happens and what follows from it.

A machine is wrong differently than a person

When you maintain a knowledge base by hand, your mistakes are slow. You forget a link. You file a note in the wrong place. You notice weeks later, because you walk through your own filing.

A machine-maintained base fails differently. It writes faster than you can read — that is the point. And because nobody checks every page, a wrong figure stands exactly until it catches someone's eye at the worst possible moment.

The crucial part: these errors do not look like errors. You can spot a hallucination by its content — a study that does not exist, a number nobody ever published. What happens here sits one level below that. The content is fine. The bookkeeping about the content is not.

Four ways a base drifts from itself

1. It counts what it cannot list

In our system, "which sources back this page" was recorded in three separate places: the citation list the Sources section renders from; a stored number the interface displays; and link rows that "not yet in your wiki" is computed from.

Three records of one fact, written by two code paths with different formulas. Nothing kept them equal. One page displayed three sources with two link rows behind it.

One direction of that drift is merely imprecise. The other is dangerous: when the number is higher than the citations, the page claims evidence it cannot enumerate. That is exactly the fabrication a cited knowledge base exists to prevent — except it does not happen while writing. It happens while keeping records.

2. It cites what you deleted

Delete a source from your collection and the link disappears automatically — the database clears it. The citation on the wiki page stayed. Title, address, counted in the total.

So the page carried an article as evidence that you had deliberately removed. And because the reference no longer led anywhere, you could not even check it without digging through the data.

Fixing it revealed something sharper: removing a citation is not deleting from a list. The prose cites by position — "this claim rests on source number two". Take number one out and number three slides into position two. The sentence stands word for word, and the evidence underneath it has become a different source. Removing a citation means renumbering every later marker, or the cleanup does more damage than the defect.

3. It stops silently

Two of seven sources in our collection had passed every gate — text extracted, summary present, not excluded — and still had no wiki page. No error. No note. Nothing.

The reason was mundane and all the more instructive. The agent reads the source's summary first and is told to stop if it is missing. That stop is a clean run: no exception, no timeout. The failure marker the system did have only caught crashes. The case that actually occurs left no trace at all.

Meanwhile the wiki page said: "4 bookmarks are not yet in your wiki. Pith is building them automatically." A promise that had gone unkept for those two sources for weeks, without the product noticing.

4. It credits you with what the machine wrote

Our version history records who changed a page — a person, a connected application, or the system itself. Thirteen of thirteen versions were attributed to the person. Not one to the machine.

The cause sits deep in the plumbing: the write runs in the background, started from the request in which you saved something, and inherits that request's context. The comment in the code even stated that background jobs never set authorship. They do not set it. They inherit it.

So the history could not answer the one question it exists for: what did I write, and what did the machine write?

What the four have in common

Not one of these is a generation error. No better model, no better prompt and no larger context window would have prevented any of them. They are bookkeeping errors — in the places where a system records what it has done.

And all four share the property that makes them stubborn: they are invisible from the outside. The page reads well. The sources look plausible. You notice only when you deliberately count — or when somebody asks in a meeting.

That is the price of handing maintenance to a machine. You get a knowledge base that grows without you sorting index cards in the evening. You lose the incidental oversight that sorting used to give you for free.

What follows

Not "trust the model more". Not "go back to maintaining it yourself" either — that returns you to the problem the second brain never solved.

Instead: a machine-maintained knowledge base needs an audit against itself. That is a property of how it is built, not an add-on.

Concretely, three things.

Use the redundancy instead of fearing it. That the same fact lives in three places is not a design flaw — it is the opportunity. Three records that must agree are a checksum. When they disagree, at least one is wrong, and you know where to look.

Name one of them as the truth. Repair requires deciding which record wins. For us it is the citations, because they are the only one a reader can verify. A stored number cannot be checked by anyone; a list of sources can.

Make failure visible. An operation that did nothing must be distinguishable from one that was supposed to do nothing. Otherwise a source that fell over looks exactly like a source deliberately passed over — and one of those needs your attention while the other does not.

Why we are writing this down

All four findings come from our own system. They are fixed, and there is now a report that compares the records and a repair that reconciles them.

But the point is not that we fixed them. It is that they arose at all — in a system built for provenance from the start, by people paying attention to exactly this. Anyone running an LLM-maintained knowledge base who has never audited it probably has these errors too. They just do not know yet.

A knowledge base that presents itself as infallible is precisely the one you cannot lean on in front of a client. One that tells you where it contradicts itself is worth having.