## TL;DR
Knowledge bases rot because nobody owns them, so give every article an owner and a review date. High-risk articles get reviewed quarterly, everything else yearly, and agents get a one-click flag that routes straight to the owner. Stale docs are a maintenance system problem, not a writing problem.

## The query

```text
how to keep a knowledge base from going stale
```

## Use this when

- Articles contradict what the product actually does
- Agents stopped trusting the docs and answer from memory
- Nobody knows who owns which article
- The help center hasnt had a systematic review in over a year

## Not for

- Writing new articles from scratch
- Choosing docs or help-center tooling
- Translating articles into other languages
- SEO strategy for the help center

## Steps

### 1. Assign one owner per article

Every article gets a named human, not a team. The owner doesnt have to write it, but they are the one who gets pinged when it is wrong.

Expected output: zero articles without a named owner.

### 2. Set review dates by risk, not by calendar

Pricing, security, and setup articles: review quarterly. Feature how-tos: twice a year. Evergreen concepts: yearly. Risk decides the cadence.

Expected output: a review schedule where the dangerous articles surface first.

### 3. Give agents a one-click "this is wrong" flag

A button on every article that sends the owner the article link plus the agent's note. No forms, no tickets, one click.

Expected output: agents report stale docs instead of silently working around them.

### 4. Run a quarterly rot sweep

Pull the bottom 10 percent by views plus everything past its review date. For each: update, merge, or delete. Deleting is a valid outcome.

Expected output: the article count shrinks or stays flat while accuracy rises.

### 5. Tie article updates to product releases

Make "docs updated" a checkbox in the release process. The person shipping the change owns the doc update, not the docs team.

Expected output: articles change the same week the product changes.

## Ready-to-use ownership block

```text
Paste at the bottom of every article:

Owner: [name] | Review by: [date] | Risk: [high/medium/low]
Found something wrong? Click "Flag this article" and the owner
hears about it today.

High risk (pricing, security, setup): review every 3 months
Medium risk (feature how-tos): review every 6 months
Low risk (concepts): review every 12 months
```

## Variant phrasings

### preventing outdated help center articles

Ownership plus review dates plus the one-click flag. The flag is the early-warning system.

### knowledge base maintenance process

The quarterly rot sweep. Update, merge, or delete, and let the count shrink.

### who should own knowledge base articles

One named human per article. Teams as owners means nobody as owner.

## Why it happens

Docs are written as projects and maintained as nobody's job. The launch gets a budget and a deadline; the upkeep gets good intentions. Staleness is the default state of an unowned document, so the fix is ownership with teeth: a name, a date, and a flag button that makes neglect visible.

## Edge cases

- Orphaned articles whose owner left: the rot sweep reassigns them. Unassigned for two sweeps means delete or merge.
- Articles nobody views: low views plus old review date usually means delete, not update.
- Fast-moving beta features: mark them beta at the top with an expiry date instead of pretending they are stable docs.
- Translated articles: the flag must exist in every language, and fixes propagate from the source article within a week.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1hy4UFJ_pi6VNgp9E2uWeg