How to Maintain an AI Wiki: Give It Permission to Forget

I asked my AI to check the wiki that helps me research and write this blog. It fixed some links, cleaned up a few inconsistencies, and came back with a list of aging information to revisit. Looking at that list, I realized I didn’t want to keep maintaining all of it.

Some of those details could simply go.

I still love the wiki format. My earlier guide to building a personal AI wiki with Claude Code and Obsidian covers the setup: sources go in, the AI synthesizes them into connected pages, and you build on what you’ve already learned. This is the follow-up about living with one as the information gets older.

This followed an earlier cleanup where I asked the AI to evaluate how lean the vault was. When it asked where I felt the bloat, my answer was the log. As I put it at the time:

My brain forgets most things, and it’s probably the way a brain should work. I don’t need a record of every change.

I wanted the system to have permission to forget. Keeping every model name, price, and resolved maintenance note accurate forever doesn’t necessarily help me or my readers make better decisions.

The rule I’m working toward is simple: before you refresh an old claim, decide whether it still needs to be there. Keep the useful lesson. Check the details when you need them. Let the rest go.

Here’s what we’re already doing, and the next change I’m making to how I think about stale information.

Start with the job your wiki does

My wiki supports this blog. It holds concepts, sources, experience, and ideas I can use to produce useful articles. That purpose gives me a way to judge what belongs.

A page explaining how to evaluate an AI workflow can remain useful through several generations of models. A sentence naming the current best model creates a different obligation: someone has to keep checking whether it’s still true.

Put enough of those sentences into a wiki and an ordinary cleanup becomes a research project.

The latest check made that visible. The wiki’s file links resolved, but older model examples and product details still came back as follow-ups. An automated check—often called a lint—can tell me where to look. I still have to decide whether fixing the old claim would make the page more useful.

For your own wiki, start with one sentence describing its job. “Help me write practical articles about AI” makes different retention choices possible than “preserve the evidence behind this research project.” A personal journal has a different job again. An old entry can be valuable precisely because it records what you thought at the time.

Remove details that keep expiring

One page in my wiki discusses the cost of AI. It names model tiers, but it also contains a more durable recommendation: establish a quality baseline on a real task, then test whether a cheaper option does the job well enough.

That recommendation is what I want to keep.

Here’s the kind of rewrite I mean. These are illustrative versions of the distinction:

The first two changes remove details that would otherwise need repeated verification. The third stops the maintenance process from creating its own growing pile of files.

Specificity still matters when someone needs it. If you’re choosing a subscription today, today’s price belongs in that decision. If you’re following a setup procedure, the correct menu or command matters. A useful example can also retain its original date and product version when that context explains the result.

The test is whether the detail helps you understand or act. A model name that serves only as decoration can disappear.

This broader pruning approach is the next refinement for my wiki. I haven’t applied it across every page or measured an improvement in answer quality. The retention practices below are already in place.

Give useful knowledge and work history different lifetimes

The earlier cleanup started with the instructions. They were helping create the accumulation: outputs were supposed to be kept permanently, logging requirements covered almost anything the agent did, and the publishing workflow contained conflicting directions about keeping or deleting completed records.

Deleting files while leaving those rules in place would invite the same clutter back.

We replaced the permanent-retention language, corrected the conflicting workflow instructions, and moved detailed writing and publishing procedures into files read when those tasks need them. The rules now let operational history expire.

For your own cleanup, ask the AI to check the instructions that produce the files as well as the files themselves. A rule requiring a new report after every successful check deserves scrutiny alongside the pile of reports it created.

Put information in the place that owns it

A useful lesson belongs on the relevant concept page. The state of an article belongs with that article’s active work. A published post belongs in the published-content inventory.

Once the information is there, the system usually doesn’t need to narrate it again in a main log, a session log, and a separate report. Each extra copy is another place that can fall out of sync.

For your wiki, this can be as simple as telling the AI: when a decision changes, update the page that owns the decision. Add a separate history note only when the history itself is useful.

Let operational logs expire

My main log keeps at most three calendar months. A separate learning inbox holds possible lessons until they’re incorporated or dismissed; unresolved entries also expire after three months. That earlier cleanup reduced the learning inbox from 83 entries to six actionable ideas. The six still had a possible job to do.

That limit applies to operational notes. It doesn’t give the AI permission to delete substantive research, personal experience, or original evidence because a date is old.

During the latest cleanup, two log entries had reached the cutoff. They contained source details that weren’t yet preserved on the concept page: publication dates for two videos and the circumstances of a Wikipedia text capture.

The agent moved those details onto the page they supported, explicitly marked missing information as unknown, and then removed the expired entries. The useful material survived without keeping the whole account of the ingest session.

The earlier review had exposed why this mattered: the log was also helping the agent recognize sources it had already processed. Deleting it without preserving source identity would remove information used for another job.

The current rule is to keep the title, author, URL when available, and publication or watch date with the knowledge the source supports. The agent checks those pages and the recent log for duplicates. We didn’t add a permanent source registry just to make forgetting possible.

Before removing a record from your own wiki, check what else depends on it. Preserve that useful information where it belongs.

Keep one current maintenance report

A recurring check replaces its previous report. Anything genuinely unresolved carries forward after checking whether it still applies. A clean result needs only a brief statement.

The rules also tell the agent not to write a new log entry announcing that it pruned the log. Otherwise, forgetting becomes another thing the system preserves forever.

Choose whether to keep, verify, merge, archive, or remove

I don’t want “old” to become an automatic delete instruction. I want the agent to explain what value would survive a cleanup.

This is the decision table I’d use for a first pass:

My original wiki article recommended archiving processed raw sources. That’s a useful starting point, and I’m refining it around what needs to survive. Some originals deserve preservation: interview notes, your own observations, an unavailable source, or research whose exact wording matters. A citation alone won’t replace those.

An expired cleanup report is different. Moving every disposable file into an archive would keep the same accumulation under another folder name.

For whole pages, compare the contents before deleting anything. A similar title doesn’t prove duplication. If a small part is still useful, move it into the page where it belongs and repair incoming links before removing the old page.

For unresolved source disagreements, preserve the disagreement. Tidying it away would make the wiki less trustworthy.

Give the AI a bounded maintenance instruction

You can try this without redesigning your whole wiki. Choose one topic you use, make sure you have a recoverable copy of the files, and ask for a small pass.

Here’s the instruction I’d use:

Review the wiki pages about [topic]. The wiki's purpose is [purpose].

Before proposing a refresh, decide whether the detail still helps that purpose.

Keep useful explanations, personal experience, source attribution, and meaningful disagreements. Verify a changing fact when it is necessary for the current task. Suggest removing incidental stale details when the supported lesson survives without them.

For each proposed change, show what would be removed and what would remain. Do not replace an old specific claim with a broader claim its source does not support.

Preserve unique source evidence before deleting or merging anything. Do not delete original sources, personal records, or whole pages without my approval. Repair links if an approved change moves or removes a page.

Follow the existing retention rules for operational logs and reports. Keep the result brief, with concrete unresolved decisions. Do not create new archival summaries of disposable history.

Show me the first small batch before applying it.

After you’ve reviewed a pass and agreed on the boundaries, put the reusable rule in the instruction file your agent follows for that wiki. In this vault, shared policy lives in AGENTS.md. Your setup might keep it in CLAUDE.md or another rules document.

Replace conflicting instructions when you do this. “Preserve every change forever” and “let resolved work expire” shouldn’t both remain active and leave the agent to guess which one you meant.

Check changing facts when you use them

A page’s age tells you when it was edited. It doesn’t tell you whether its advice is wrong—or whether someone checked every claim during the last edit.

One page in our lint pass was missing its update date. We restored it with an explicit note that this was a metadata repair and the product claims hadn’t been reverified. That distinction matters. Fixing a heading link shouldn’t make an old product claim look newly confirmed.

When I’m turning wiki material into an article, the claims readers will rely on still need checking. The wiki helps locate the ideas and their evidence; saving a claim there doesn’t make it permanently true.

For your own use, check the facts that affect the task in front of you. Before following an export procedure, verify that procedure. Before choosing a plan, check the relevant limits. Leave an older conceptual explanation alone when it still does its job.

If you can’t verify a necessary detail, mark it as unverified and avoid relying on it. Removing incidental detail is useful; removing a limitation that changes the answer is careless.

Start with one page you still use

This approach fits a personal working wiki. A historical collection or a project with explicit record-keeping obligations needs different rules. Even in a personal wiki, the AI can mistake a qualification for clutter. Read what remains after an edit and check that it still says something you can support.

My next step is to apply the same judgment to the stale details the lint surfaced: decide which are useful enough to verify and which can leave. I don’t need the whole wiki certified as current before doing that.

Try it on one page. Keep the part that helps you think or act, preserve the evidence it needs, and remove one detail you no longer want to maintain.

A useful wiki is allowed to get smaller.