Building a Personal Wiki Your AI Actually Reads — A 3-Month Log

Why do second brains pile up but never get used?

It isn’t the tool. The reader changed and the structure didn’t.

Switching note apps or rebuilding your tag system rarely changes much. Most notes are written on the assumption that “I’ll read this again later.” The catch is that the re-reading turned out to be real work. I spent a lot of time checking notes, moving them around, and reshaping them.

Once I handed that upkeep to an LLM, the time cost dropped sharply. But the one opening the repository and judging it was no longer me. It was the model. A person opens a note already holding the context. A model comes in every time knowing nothing. That is why a memo that was enough for me looks like a pile of unsupported sentences to the model.

So since May 8, 2026 I have run a personal wiki with that premise flipped. The primary reader is the LLM, so I favor structure a model can judge over prose a person enjoys. The LLM-Wiki pattern Andrej Karpathy published in April 2026 was the starting point, and after three months and five rounds of revising the rules it reached its current shape.

How is a wiki for an LLM different from notes for a person?

Every page is built to answer “should I read this page right now?” within ten seconds.

Each page opens with a four-sentence preamble that comes before the body. It states what the page is, why it exists in this repository, and the one fact the reader has to take away. One more rule sits on top: the first sentence carries the most weight, and relevance has to land even if you stop after it. The model really does stop reading at the first sentence.

The structure of the notes people write depends on how much time they had the moment they wrote them. A memo jotted down in a hurry stays without rules or context, and only the notes from an unhurried day come out organized. Across the whole repository the quality is bound to be uneven. An LLM wiki removes that variance by making structure a rule instead of a function of spare time. The four-sentence preamble and the first-sentence priority are the minimum you keep even on a day with no time.

That form works by making irrelevant pages easy to drop fast. When a search turns up ten candidate pages, throwing nine of them out quickly beats reading all ten in full.

Why must the source never be edited?

The moment interpretation and source mix, you can no longer trace what the evidence was.

The repository splits into two layers. The lower layer is the clipped source. Articles, papers, and video transcripts go in untouched. The upper layer holds the concept and entity pages drawn from those sources. The lower layer is immutable. Once something is in, not even a single typo gets fixed.

What enforces this is a hash. Every source file carries the sha256 of its body in the frontmatter, and a check script fails when the value drifts. If a source changed, you don’t fix it. You fetch it again and reinterpret. That way any claim in the upper layer can always be traced back to a specific point in a specific source.

Ask a model to summarize and sentences that were never in the source start slipping in. Locking the source as immutable lets you pin down where that contamination slipped in.

Honestly, this rule confused me most while I was adopting it. It runs straight against the old habit of fixing anything the moment it catches your eye. Touching a source broke my git sync a few times. The mistake only went away once it sank in that a source gets refetched, not edited.

Do all notes have to become wiki pages?

No. A note is promoted only when it shows up in two or more separate sources, or when a single source is entirely about it.

Without a threshold the repository fills with pages used once and never again. A concept mentioned once stays in the source layer; it becomes a page when you meet it again in a second source. The fact that it showed up twice is itself evidence that the concept actually recurs in what I care about.

The size limit serves the same purpose. A page aims to stay under 200 lines and gets split past 300. Another rule requires at least two links from each page to other pages. A page connected to nothing gives no context even when search finds it.

Here are the numbers after three months. From 93 sources (30 articles, 63 transcripts), 97 upper-layer pages were promoted: 76 concepts, 20 entities, one query record. A promotion ratio near one to one is also a sign the threshold is loose, so I read it as something to tighten in the next revision.

How do you decide when the AI should read your notes?

You don’t leave the read-or-not call to the model. You encode it in trigger words.

Reading the repository every time is slow and expensive. Never reading it defeats the point of keeping a personal wiki. So I split it into four tiers.

Tier one is a forced lookup. If a question contains words like we, last time, decision, or strategy, or a proper noun registered in the repository, it always reads. Questions whose answer lives only in a personal repository mostly arrive carrying these words. Whatever pages it reads get cited in the answer to show the basis.

Tier two is a light skim, and tier three names the areas not to read. Ordinary coding problems, outside news, and plain translation don’t open the repository even if a trigger fires. “Should we use React?” catches on we but has no answer in the personal wiki. Tier three is there to clear the false positives tier one produces. Tier four is a switch the user turns on and off directly.

Written out this way, the problem of the model judging differently every time goes away. When a lookup misses, you fix the rule, not the prompt. That part matters more.

What happens to old content when a fact changes?

You don’t delete it. The body is rewritten to the current fact. The old claim moves down to a history section at the bottom of the page, and the change gets one line in a separate log.

The newer-dated side usually wins. When it isn’t clear which one is right, the two claims sit side by side with a conflict mark. Only silent overwriting is banned.

I made the rule to keep the model from repeating a past wrong answer, but its real use came from somewhere else: retracing why I judged the way I did. A repository left with only conclusions gets hard to trust over time. What lets you trust the current conclusion is the trace of what changed still sitting there.

After three months, what stuck?

The two that clearly worked were the four-sentence preamble and source immutability. The preamble lifted lookup quality right away, and immutability let me track where things went wrong when an answer looked off. Both are rules rather than tools, so they carry over even if I switch note apps.

The tag system was the opposite. It kept needing attention. I settled it by fixing eight top-level categories and only growing the sub-tags, but tags are still the part that drifts most often.

So does LLM-wiki replace Zettelkasten and PARA?

No. These days I actually lean on PARA more.

My second brain runs as an Obsidian vault that combines LLM-wiki with PARA. LLM-wiki has fully replaced the Zettelkasten I used to layer on PARA.

What I reach for more day to day is PARA. That’s because my CTO work is mostly managing the state of ongoing projects and research. I lean on it more when I review content and research written by colleagues, too. LLM-wiki pulls its weight somewhere else: research and content production, where I lift concepts out of scattered sources and reach for them over and over.

So there’s no need to treat LLM-wiki as a replacement for every note. PARA fits the work of managing state. LLM-wiki fits the work of stacking evidence you’ll write from later. If I were rebuilding a second brain, I’d order it like this. Put folder structure and app choice off until later, and decide first who will read the note. Then write down, as rules, the minimum that reader needs in order to judge. The rest follows from there.

These days what reads and writes this repository at dawn is not a person. How that unattended automation is wired up is in the personal AI automation log, and applying the same premise to AI crawlers, when rebuilding this site, is in the GEO-native site build.