How to handle stale documents in a knowledge base
After a knowledge-base document is published, write the review frequency and the owner, and say whether a stale PDF or wiki page is replaced or withdrawn, so retrieval does not keep citing a rule that no longer stands. Versioning decides which file is marked current and who may mark the previous file withdrawn. Wrong-answer intake decides what happens after someone says a reply was wrong. This note decides whether a file may still be cited once its review date has passed.
On this page
- Keep freshness apart from versioning and from wrong answers
- The practice asks for a frequency and a named person
- Write the frequency and the owner on the current file
- Past the predicted date, retrieval stops citing the file
- A replacement points at the new current text
- Withdrawing without a replacement says there is no next version
- Wiki pages and PDFs share one review line
- A file is being managed when frequency, owner, and outcome are written
Keep freshness apart from versioning and from wrong answers
The version mark answers which file on the store is the current text, and who may mark the previous draft withdrawn. Wrong-answer intake answers what happens after someone says a reply was wrong: the question, the wrong reply, and the correct source go on one line, and the next step is to correct the document, recut the passage, or retest retrieval. Freshness answers a different question. The document is already in the library. When is the next review, and if that day passes with no confirmation, may retrieval still cite it as the rule. The three can point at the same storage path. How the version mark is written stays in the versioning note. The intake for a reported error does not stand in for a review that has fallen due. See How to manage document versions in a knowledge base and How to record and fix a wrong knowledge-base answer.
A reply carries a path, a version, and a section. See How to attach sources to a knowledge-base reply. Which documents may stand as the rule is in How to build an enterprise knowledge base. Chunk boundaries are not recut because a review date arrived. See How to choose chunk boundaries for a knowledge base. The delivery scope sits under Internal knowledge base and assistant.
The practice asks for a frequency and a named person
W3C Data on the Web Best Practices, read on 28 October 2026, is a W3C Recommendation of 31 January 2017, published by the Data on the Web Best Practices Working Group. The top of the page says to check the errata. On the day of reading, the body of the page did not list errata entries. Best Practice 21 is titled Provide data up to date. It says to make data available in an up-to-date manner and to make the update frequency explicit. The section says the availability of data on the Web should closely match the time the data was created or collected, and that aligning publication with the update frequency encourages confidence and reuse. The intended outcome is that the latest copy online generally reflects the latest data released by any other channel, and that new data is published as soon as practical after it becomes available.
The same section says new versions can be posted on a regular schedule, that publication can be a deliverable in the release process, and that assigning one person to the task can help keep the data from going stale. It also says you can state the expected frequency in human-readable text and in machine-readable metadata. The test is that the update frequency is stated, and that the latest copy is no older than the date the frequency predicts. The section's bus-stop example sets the frequency as annual. That frequency belongs to the example. It is not a cycle the knowledge base has to adopt. The company writes its own review frequency for each rule, with who set it and on which day.
Write the frequency and the owner on the current file
On the current file, beside the title, version, and owner the version mark already carries, write the review frequency and the date this review was completed. The frequency is in the company's own words: each quarter, each half year, or a fixed month and day for that kind of rule. A frequency with no completion date cannot predict the next review, and the test in that section cannot be run. The owner is the person already named on the version mark. The review does not pick someone who is not written on the file.
A date on chat, on email, or on a local copy is not a completed review. It is completed when the owner writes the date on the current file in the store. If the owner is away, a colleague who is present does not write that date for them. The author of a draft may remind the owner that the frequency is coming due. The date is still written by the owner.
Past the predicted date, retrieval stops citing the file
Under the test in that section, the item fails if the latest copy is older than the date the frequency predicts. For a rule in the knowledge base, the use is this: the predicted day has passed, the owner has not written a new review date, and a new current text has not been put in place, so retrieval does not cite this file as the rule. The reply says the review date has passed and names the owner. A passage that is still visible in the old citation is not sent out before the review is completed.
Before the predicted day, a newer PDF in chat does not withdraw the current file on the store. For the newer file to become current, the versioning note still applies: the owner marks it current in the same change that marks the previous file withdrawn. If the review passes and the text is unchanged, the owner updates only the review date. The version number may stay as it is. A change to the text is a replacement.
A replacement points at the new current text
When the owner decides the text must change, the new file is marked current under the versioning note, and the old file is marked withdrawn in the same change, with the date. The freshness line then records the old path, the new path, the date of the change, and the owner. Retrieval cites the new current text. The old file can still be read for comparison. It does not disappear from the library without that line.
Dropping a new PDF into the same folder, without those marks, leaves both files visible to retrieval. Until the marks are written, the file past its predicted date is not cited, and the new file is not yet current. A colleague saying in chat to use the new one does not replace that line.
Withdrawing without a replacement says there is no next version
Some rules end with no successor, for example when the policy itself is cancelled. The owner changes the current mark to withdrawn, writes the date and the reason, and does not point at a new file. The reason says the policy was cancelled, or a short sentence of the company's own. It is not a blank "stale". Retrieval no longer cites the file as the rule. If someone asks about the topic, the reply says it is withdrawn, gives the date, and names the owner. It does not quote the old passage as a rule that still applies.
Wrong-answer intake remains a separate door. It is used when a colleague says a particular reply was wrong. If the review date passes and nobody has reported an error, citation still stops. It does not wait for a complaint. The two can happen in either order. If the complaint comes first, the wrong-answer line is still recorded. The review date is still written by the owner. A complaint does not count as the frequency having been completed.
Wiki pages and PDFs share one review line
A PDF, a wiki page, and a file on the shared drive use the same review fields: frequency, owner, the date of the latest review, and an outcome of kept, replaced, or withdrawn. The edit time on a wiki page does not stand in for the review date. The file-modified time on a PDF does not either. If the outcome is kept, the text may stay as it is, and the date must be written anew. If the outcome is replaced or withdrawn, the index does not treat the old passage as the rule until the mark is written.
The section says machine-readable metadata for the frequency may be provided as well. If the knowledge base already has a field for it, the value matches the frequency people can read. If it has no such field, the human-readable frequency and date still stand. Citation is not held back while a format is added. If retrieval is run again, the question set stays the one in the retrieval note. See How to evaluate knowledge-base retrieval. The freshness line does not invent a hit rate.
A file is being managed when frequency, owner, and outcome are written
A file with a blank frequency, a blank owner, or a blank date for the latest review does not enter the rules that may be cited. If the predicted day has passed and the outcome is not yet kept, replaced, or withdrawn, retrieval continues not to cite it. An outcome of any of the three, missing a date or an owner, is not a completed mark.
Three checks show whether a document's currency is being managed: the frequency and the owner are on the current file, retrieval does not cite it once the predicted day has passed, and a replacement or a withdrawal is written by that owner and either points at the new text or says there is no next version. A blank item means the reply says the review is not finished, and the old passage is not quoted.