Knowledge Base Freshness: Scoring and Automated Updates

A knowledge base degrades silently. Nothing throws an error when a page becomes wrong; the reader simply trusts an outdated claim. In a wiki that compounds, that failure is worse than in a folder of documents, because a wrong claim on one page gets linked by others and becomes organized misinformation ([evidence ev-201]). Compounding Knowledge runs in both directions: connections multiply good synthesis, and they multiply error.

The answer is a maintenance pass. Wiki Lint is a periodic health check where the agent audits the wiki for contradictions between pages, claims superseded by newer sources, orphan pages with no inbound links, concepts mentioned but lacking their own page, missing cross-references, and gaps a search could fill ([evidence ev-201]). Freshness scoring is how you decide which of those findings to fix first.

Freshness is not the same as age. A page from long ago that quotes a stable definition may be perfectly current; a page added recently that quotes a version number may already be wrong.

Three inputs make a workable score:

• Time since last reconcile. Not the page's created or updated date, but how long since its claims were checked against sources.
• Volatility of the claim. Facts that move, such as versions, counts, dates, and prices, versus stable reference material that does not.
• Dependency weight. How many other pages link to this one. A heavily linked page carries its errors further, so it deserves earlier review.

Higher score means review sooner. Lower score means the page can wait.

Read the table as a triage tool, not a formula. The point is to sort the pages of a wiki into "review now," "review soon," and "stable." A page that is old, volatile, and central belongs at the top. A stable reference page with few inbound links can wait almost indefinitely.

The three inputs interact, and the interaction is the useful part:

1. Old plus volatile. A page nobody has checked that quotes moving values. This is where silent drift lives.
2. Old plus central. An anchor page or hub. Errors here propagate through every page that cites it.
3. Volatile plus central. A frequently changing figure that many pages depend on. Even a recent reconcile goes stale fast.

A page low on all three is not a maintenance problem and should not consume review time.

Scoring a wiki by hand does not scale, and it is exactly the kind of work an agent handles well. An automated freshness pass is a scheduled lint that:

1. Lists pages sorted by freshness score.
2. Flags pages whose status is stale or whose updated date is older than the threshold you set.
3. Proposes new sources or questions that would reconcile the oldest, most volatile pages.

This is the lint operation applied on a schedule ([evidence ev-201]). It does not need to rewrite anything. Its output is a work queue: here are the pages most likely to be wrong, in the order worth fixing.

The cheapest freshness fix is to stop storing values that move inside prose. A page that quotes a moving value — a version, a count, a date, a last-synced marker — has copied state to a second home, and it drifts silently. Keep those values in frontmatter or in the repository so tooling can read them live, and write stable values in full in the body.

This one practice removes a large share of future freshness work. If the number lives in one place, updating it updates every page that reads it. Copied into many paragraphs, it needs many edits and at least one will be missed.

Freshness is not only about dates. When a newer source contradicts an older page, note the contradiction on both pages rather than silently overwriting one with the other ([evidence ev-201]). The reader then sees that the source base moved, and why. Overwriting hides the change instead of resolving it.

Orphans and dangling links are freshness signals too. An orphan page with no inbound links may simply be forgotten, and a link to a page that no longer exists is rot ([evidence ev-201]). Both are cheap to detect in a lint pass and cheap to fix: add the missing cross-reference, or remove or redirect the dead link. A Knowledge Graph with broken edges is not a smaller graph; it is a graph that lies about its own shape.

Two files carry the freshness of the system itself.

The Index File is updated on every ingest. A stale index causes missed pages, because the agent reads the index first and may never learn that a newer page exists ([evidence ev-201]). An accurate index is part of health, not a separate concern.

The Changelog is the timeline: an append-only record of ingests, queries, and lint passes. It lets the agent see what was done recently and supports freshness auditing after the fact ([evidence ev-201]). If you cannot tell when a page was last touched, you cannot score it.

Freshness maintenance is change management, and the discipline that governs retrieval tuning applies here as well. Cherry Studio recommends validating retrieval with 3–5 fixed real questions and changing one setting per round ([evidence ev-206]). If the correct chunk never appears, it is a parsing or chunking problem; if it appears but ranks low, add a reranking model; if it is filtered out, lower the similarity threshold.

The rule behind that method is attribution. Do not change the embedding model and the chunk size in the same round, because you cannot tell which one caused the difference ([evidence ev-204]). Apply the same discipline to freshness: change one thing, then re-measure. When you update sources, re-run the pass and compare. A freshness system you cannot attribute is one you cannot trust.

This matters most when the wiki also serves Retrieval-Augmented Generation. Retrieval quality depends on the pages it reads, so stale pages quietly degrade answers even when the pipeline itself has not changed.

A practical cadence for a personal-scale wiki of about 100 sources ([evidence ev-201]):

• Run the lint pass and export the score-sorted page list.
• Reconcile every page that is old, volatile, or central, in that order.
• Replace quoted moving values with frontmatter or live reads.
• Note contradictions on both pages instead of overwriting.
• Repair orphans and dangling links.
• Confirm the index reflects every page added since the last pass.
• Append the pass to the changelog.

The checklist is short on purpose. Freshness work fails when it is treated as a rewrite project; it succeeds when it is a small, repeatable pass that never lets the queue grow.

What is knowledge base content freshness?

Content Freshness is a measure of how current a claim is, tracked per page and scored by how long ago the page was last reconciled against its sources. A stale page is one whose claims may no longer hold.

How do you score content freshness?

Combine time since last reconcile, the volatility of the claim, and dependency weight, which is how many pages link to the page. A higher score means review sooner. The score is a triage tool, not a precise formula.

Can freshness updates be automated?

Yes. An automated freshness pass is a scheduled lint that lists pages by score, flags pages whose status is stale or whose updated date is older than your threshold, and proposes new sources or questions ([evidence ev-201]). The output is a work queue.

How should contradictions be handled?

Note the contradiction on both pages rather than silently overwriting the older one ([evidence ev-201]). The reader should be able to see that the source base changed, and why.

Why keep moving values out of prose?

A quoted moving value is state copied into a second home, and it drifts silently when the original changes. Keep versions, counts, dates, and last-synced markers in frontmatter or the repository so tooling reads them live.

The XKnow Knowledge Base at XKnow Knowledge Base is a pre-compiled LLM Wiki you own: interlinked markdown shipped as files rather than a locked service. It is written, checked with Wiki Lint, and scored against the freshness discipline described here, so the maintenance habits in this guide are built into the artifact. You get the compiled result and the method for keeping it current.

• What is an LLM wiki — the definition and the operations behind a maintained wiki.
• Karpathy's LLM wiki — the origin of the pattern this page assumes.
• add embeddings to a knowledge base — when retrieval moves from index reads to vector search.
• XKnow Knowledge Base — the compiled SEO and SaaS wiki this method maps onto.