Why Wikis Go Stale and What Changes When an AI Makes the Gaps Visible

It is Tuesday morning. A new colleague in the sales team of a mid-sized machine builder is planning her first customer trip and wants to know how much she may spend on a hotel. In the wiki she finds the page “Travel Policy”: lodging up to 120 euros per night. No author is named, and the last edit was four years ago. Two folders over sits a circular from management dated March, and it says 140 euros. Both documents can be opened, and both look equally official. She books a room for 130 euros, the expense report gets stuck, and for a week three people argue about which number applies.

The scene is made up. But every company with a wiki that has grown over the years knows a version of it.

This article makes one argument: wikis do not go stale because people are careless. They go stale because nobody can see which page is no longer true, and because neither a person nor a date is responsible for the page. That is a design flaw, not a character flaw. It can be fixed once an assistant answers from your documents, because then gaps, contradictions and age become visible at the exact moment someone needs an answer. If you turn that into small review tasks for named owners, upkeep becomes a steady effort of, in our example calculation, about half an hour per person per month. You then no longer need the big project that starts going stale the day it ends.

Why Wikis Go Stale, and It Is Not Laziness

A wiki is built like a book that only gets written and never revised. Creating a page has a moment: a project, a launch date, usually some enthusiasm. Changing it has none. Meanwhile reality keeps moving: prices, contacts, software versions, rules. None of that triggers a task in the wiki. Five mechanisms keep the decay going:

• Writing is an event, maintaining is not. A new page comes with a reason, time and often some credit. Correcting a single number comes with none of that.
• Stale pages look like current ones. A page from four years ago is formatted exactly like one from yesterday. Whoever reads it gets no warning.
• “The team” is responsible. When a page belongs to everyone, nobody looks after it. When the person who created it changes jobs, ownership disappears quietly.
• Errors are rarely reported. Someone who notices a mistake asks a colleague and moves on. The correction ends up in the colleague's head, not on the page.
• Nobody sees what is missing. A page that never existed leaves no trace. The question nobody could answer shows up in no statistic.

This produces a cycle many wikis know: reality changes, the page stays, nobody notices, and trust drops. Because people trust the wiki less, they ask colleagues, and because the wiki is used less, even less gets noticed. The decay stays invisible. The second loop in the graphic shows what changes when every question leaves a trace.

Enlarge

Why the Big Wiki Clean-Up Is Not Enough

The usual reaction is a clean-up project: a working group, a spreadsheet with 500 pages, three weeks of effort. It helps, but only for a while, for three reasons.

First, afterwards every page has the same age. A year later they are all due at once, and the wave returns. Second, the project treats all pages alike, although only some of them are ever asked about. Time goes into pages nobody reads, while the three important ones get the same ten minutes. Third, nothing changes in the structure: after the project there is still no responsible person and no signal when a page stops being true. The example calculation further down shows how the effort can be spread differently.

What an AI Makes Visible: Three Signals

Searching a wiki gives you a list of hits. Whether the page fits is decided by the reader alone, and when the reader decides it does not, nobody finds out. The situation is different when an assistant answers from the documents. It has to either find something or say that the documents do not contain it, and it should name where it got the information. An assistant like the one in TheroAI answers with numbered sources, so every statement leads back to a passage. That turns ordinary use into a source of signals a wiki alone cannot give.

A caveat up front: how much of this a tool evaluates automatically differs from product to product. We describe a mechanism here, not a performance promise. Even without any automatic evaluation you can start by looking, once a week, at the questions the assistant could not answer from your documents.

Enlarge

Signal 1: The Unanswered Question

Someone asks: “How do I register a business trip abroad?” The assistant finds nothing suitable and says so: not in the documents. Once, that is chance. When the same question comes up three times in a week, a page is missing. In a classic wiki the question would simply have gone to a colleague, and the gap would never have been noticed. A useful rule: every answer of “not in the documents” is an order for a page.

One reservation belongs here. A missing answer can also mean that the person asking is not allowed to see the matching document. A good system carries over the permissions of the source, which is intended and not a gap in the wiki. So before anyone starts writing, check whether the page is really missing or just not visible to that person.

Signal 2: The Contradiction

Two sources answer the same question differently: the travel policy says 120 euros, the circular says 140 euros. In the wiki the reader sees only the page they happened to land on and has no reason to doubt it. An assistant that backs every statement with a source can show both passages side by side as soon as it finds them. It cannot decide which one applies, a person does that. But the contradiction is no longer invisible. In the product, readers can also request a review and choose “Conflicting information” as the reason. The request goes to the responsible expert, and other readers do not see the comment.

Signal 3: The Old Document Without an Owner

The third signal is the quietest. The onboarding checklist is cited often, but it was last reviewed 14 months ago, and nobody is entered as responsible. In the product you see a document's review status in knowledge search and on the document itself, along with the responsible person. In the task list, a missing owner is flagged with the note “Responsibility missing”. This signal is especially valuable because it shows the problem before it hurts anyone.

Owners and Review Dates: The Minimum per Page

The signals only help if they reach someone. For that, every page the assistant may cite needs three details: a named owner, the date of the last confirmation and a deadline for the next one. Everything else, folders, labels, templates, comes second.

A good owner is whoever would notice immediately if the page were wrong. That is often not the person who wrote it. The price list belongs to sales, the travel policy to HR or accounting. In the product, a person or a group can be entered as responsible, with optional deputies. The chosen person or group needs access to the source. If responsibility is missing, the list says so openly, which makes it visible when someone leaves the company.

The deadline depends on the consequences of an error. A wrong hotel limit is more annoying than an outdated lunch menu. The values below are suggestions to adapt, not rules:

In the product, administrators set a maximum review interval in days. Whoever confirms a page chooses in how many days it should be reviewed again, or sets a custom date. So the interval is a decision per page, within a frame the company sets.

“Reviews”: How Verification Tasks Keep Upkeep Small

Verification in TheroAI turns those three details into tasks. On the personal start page, “My workspace”, the “Reviews” list shows the documents and answers waiting for your verification, each with its review status, the responsible person and the due date. A link leads to all verification tasks. There you find the views “My tasks”, “Your content” and “Completed”, and for knowledge moderators an additional moderation inbox.

A review is deliberately short. You open the current content and read it. Then you choose “Verify document”, tick a box to confirm that you have reviewed the content, and set when the next review is due. The confirmation applies to exactly the version of the content you saw. If the document changes afterwards, the status switches to “Changed since review”. So a correction does not silently carry the old tick forward.

Readers can contribute as well. Whoever notices something off chooses “Request verification” and gives a reason: may be outdated, conflicting information, unclear statement, not yet reviewed or another reason. The request lands with the responsible person. A remark that would otherwise fade in a colleague's head becomes a task with an addressee.

When content should no longer apply, you mark it as outdated, with a reason and, if you like, a replacement document. The source is kept, readers see the notice, and according to the notice in the interface the assistant does not use the content as a current basis by default. This is the quickest form of upkeep: taking a page out of circulation takes seconds, while rewriting one often takes an hour.

Enlarge

Two limits belong to an honest description. First, “Verified” is a person's statement, not proof. It says that someone looked at exactly this version and confirmed it, not that it is free of errors. Second, verification changes no permissions: a professional review grants no reading rights and does not lift a block on AI use of the content. The documents themselves stay where they are and reach knowledge search through connectors.

Upkeep as a Small, Steady Effort: An Example Calculation

How small is “small”? The following example calculation uses round assumptions. It is meant to show the order of magnitude, not a forecast for your company.

Enlarge

The surprising part of the calculation: the hours are the same. Whether you invest 80 hours at once or 6.7 hours per month, the year comes out equal. The difference lies in the shape. The project asks a team of twelve for roughly 6.7 hours each within a few weeks, almost a full working day, and produces 480 pages with the same date. Continuous review asks about 33 minutes per person per month, and no confirmed page is older than twelve months. After 24 months without further upkeep, every confirmation from the project is 24 months old. If you repeat the project every year, both paths cost 160 hours over two years. Upkeep in a rhythm is then not cheaper, it is better distributed, and you can set intervals by consequence and use instead of treating every page alike.

A note on scale: ten minutes is an average we assume. Many pages are confirmed in two minutes, some take an hour. A page that needs more than half an hour is no longer a review but a rewrite, and should be handled as its own task.

How to Keep the Effort Small

• Stagger the deadlines. Do not put all pages on the same date. Spread the dates across the year on the first pass so that no wave builds up.
• Order by use. Pages that people ask about often, or that the assistant cites frequently, get shorter intervals and an owner first.
• Retiring counts as a review. Marking a page as outdated takes seconds and reduces the load without losing quality.
• Reviewing is not rewriting. Whoever compares a page with reality and confirms it, or fixes small errors, is done. Bigger rebuilds belong in a task of their own.

Getting Started in Four Weeks

You do not have to touch the whole wiki. Start with what people actually ask.

Enlarge

1. 1.Week 1, collect questions. Write down the 20 questions asked most often in daily work. Ask in the team, in HR, in sales. The number 20 is a suggestion, what matters is a manageable start.
2. 2.Week 2, name owners. For every question, find the page that answers it and enter one person as responsible. If the page is missing, that is already your first result: you have found your first gap.
3. 3.Week 3, first review. The owners open “Reviews”, read the pages and confirm or correct them. Have them choose different deadlines so that no wave builds up.
4. 4.Week 4, set the rhythm. Fix a regular slot, say a quarter of an hour a week, to look at the open review tasks and the questions without answers. After that, operation runs on its own.

What You Deliberately Do Not Do

Do not start with all pages, with a campaign or with a ranking. You do not want to collect stamps, you want the answers to be right. And avoid staging verification as surveillance. Whoever feels watched confirms quickly and does not read.

Limits, Data Protection and Works Council

Questions from employees are personal information. Evaluate them by topic, not by person: what matters is which question so often goes unanswered, not who asked it. The review history also records who confirmed a piece of content. That serves traceability, but it should not turn into a ranking of employees. A technical device that is suited to monitoring the behavior or performance of employees is subject to co-determination under section 87(1) no. 6 of the German Works Constitution Act. Involve the works council early. This is not legal advice, so clarify your individual case with your legal counsel.

On data hosting: with TheroAI, data is stored in Germany and AI processing takes place in the EU. Details are on the Security page.

Two risks are worth knowing. The first is the tick without reading: confirming pages without reading them creates false certainty, which is worse than none. Small volumes per person, an open history and occasional spot checks help against it. The second is the belief that more review is always better. Not every page deserves care. A page nobody reads does not belong in the collection.

How You Know It Is Working

Measure a few things, and measure them without target figures plucked from the air. The table below names indicators you can read from your own collection, and the direction they should move.

Expect an effect that looks like a step backwards. At the start, more gaps and more contradictions become visible than before. That is not a loss of quality, it is the collection being counted honestly for the first time. What matters is that the number of open tasks stops growing after a few months.

What You Can Take Away

If you are assessing your wiki or knowledge base, these questions help:

• Does every important page have a named person or group, and is there a deputy?
• Can readers see at a glance when a page was last confirmed and whether its interval has expired?
• Do you know which questions your assistant or your search could not answer last week?
• Can readers request a review with one click, and does the request reach a person instead of a mailbox for everyone?
• Does a confirmation apply to a specific version, so that a change resets the status?
• Is the review interval tied to the consequences of an error, and are the dates staggered across the year?

Our position: the way out of a stale wiki is not the big clean-up but feedback. Make visible what is missing, contradicting or aging, give every page a person and a date, and keep the task small. Then upkeep stays part of everyday work, and the AI answers questions from a version someone is accountable for.

If you would like to see what answers with sources and the verification of documents look like in daily work, we are happy to show you in a demo, without obligation and with examples from your industry.