Support · Documentation
Help articles that keep up with the product
Every shipped change quietly makes a help article wrong, and the customer finds out before you do.
What the worker does
Help center maintenance in Polaris is a recurring task assigned to an AI worker connected to Linear or GitHub and your docs. The worker compares what shipped against what the articles claim, delivers a list of documents that are now wrong, and attaches a rewritten draft for each. A support lead reviews the drafts in file review and publishes what is correct.
- Connections
- Linear · GitHub · Google Drive
- Cadence
- Monthly, or after each release
- Output
- Stale list plus rewritten drafts
Documentation rots at the speed of shipping
Nobody writes a wrong help article. Articles become wrong because a button moved, a plan was renamed, a limit changed, and the person who made the change had no reason to think about a page written eleven months ago.
Support finds out through tickets. The article says one thing, the product does another, and an agent spends the afternoon explaining the difference to six people.
The check itself is comparison work: what shipped, what the article claims, where they disagree. That is a task with a shape, so it can be owned.
The three kinds of stale
Worth separating, because they need different responses.
Factually wrong
The article describes behaviour the product no longer has. This one costs you tickets today and goes first in the delivery.
Incomplete
The behaviour is right and something new is undocumented, so customers cannot find a feature you built.
Structurally stale
Six articles now overlap because the product grew into them, and the customer cannot tell which one to read.
How the worker checks
| Source | What it reads | What it can conclude |
|---|---|---|
| Linear or GitHub | Shipped issues and merged changes since the last run | What changed, and when |
| Your help articles | The claims each article makes | Which claims are now contradicted |
| Support tasks | Tickets tagged as documentation confusion | Which pages customers actually stumble on |
| Web search | Your own public pages | Where a public page disagrees with the help center |
Questions people ask
+Does it need access to our codebase?
GitHub and Linear are both in the connection catalog, and either is enough to see what shipped. A worker with only your help articles and support tickets can still find contradictions, but it will find fewer of them and later.
+Can it publish the corrected article?
No. The delivery is a comment with the rewritten draft attached, and a person publishes. Documentation is customer-facing text, so it goes through the same approval as any other customer-facing text.
+How often should this run?
After each release if you ship in batches, monthly if you ship continuously. Attach it to the release task so the check happens when the risk is created rather than on a calendar that drifts.
+What does a monthly documentation audit cost?
It is billed in human-equivalent hours at about $2 each, and the formula counts observable effort including the drafts produced. A month with a large release costs more than a quiet one, and the work log shows exactly which session was which.
Related
Support work, with an AI teammate on the queue
The queue is a conveyor belt of small decisions. Sorting them is mechanical; making them is not.
A template library that stays in your team's voice
Templates go stale the same way documentation does, except a stale template gets sent to a customer.
The README describes a version of the code that no longer exists
A monthly list of statements in your docs that the code no longer supports.
Hire an AI technical writer
The documentation debt on your team is not a writing problem, it is a nobody-has-two-free-hours problem, and this is the worker for those two hours.
Connect Linear to Polaris
A Linear API key carries one person's visibility, so the account you make it on decides what every worker can see.
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.
Workstream
A strand of work that keeps going, rather than a project that ends.