How we keep our docs honest

AI wrote most of these docs from each product’s source code. Docs written that way are only worth reading if they’re right. So every claim is checked against the code, every build is checked before it ships, and the docs are tested by asking them real questions. This page explains how.

Written from the code, not from the README

Each product’s docs are written from its source repository, following a checklist of the ways a docs claim can turn out to be false. Every item on it comes from a real mistake that was caught and fixed. Two examples:

A source comment called a bundled word list “1,296 words of 4–6 letters”. The list itself holds 1,294 words of 3–5 letters. Now any number that can be counted is counted, not copied.
One product’s code had a function for automatic console speed detection, but nothing called it, so the console is fixed at 9600 baud. Now a feature is documented only when the code that runs it can be reached.

When writing the docs turns up a problem in the product itself, such as its own screens disagreeing with its code, the docs follow the code and the problem goes to the product team.

Every build is checked before it ships

The site doesn’t deploy unless all of these pass:

Every link between pages, and every link to a section of a page, goes somewhere real.
Every page belongs to a product, so search can stay inside one product’s docs.
All text meets WCAG AA contrast in both the dark and the light theme, measured in a real browser.

Can the right page be found?

The support assistant answers from these docs, and it reads only the top few search results. So every product has its own set of test questions, hundreds in all. Each question names the page that should answer it, and the test checks that search brings that page back near the top. When it doesn’t, we change the page or how search ranks it, and the question stays in the test so it can’t quietly break again.

Are the answers right?

The second test asks the support assistant itself questions about every product, several times each, on a staging copy of support.

Each answer is checked for the facts it has to state.
Some questions are traps: they ask about a feature that doesn’t exist, to tempt a made-up answer. Two separate AI judges read those answers for any claim we know is false.
Every docs link in an answer is checked to make sure the page exists.
Questions people really asked are added over time, so the test follows what people actually need.

What the tests have changed

Specific pages come first. A product’s overview page mentions everything, so it used to take search slots that a more specific page should have had. Since October 2026, the assistant uses an overview page only when nothing more specific matches.
No answers from general knowledge. When the docs don’t cover a question, the assistant says so and offers to put you in touch with a person, instead of guessing. This has been live since October 2026.
Next: questions that need two pages. When an answer has to combine two pages, we’re working on bringing both of them back together.

When the tests run

Whenever the docs search index changes.
On a staging copy of support, so every run asks the same questions the same way and the results can be compared.
Real conversations feed the tests: when the docs don’t answer a question well, it’s reviewed and can become a new test question.

Found something wrong? Tell us with “Was this page helpful?” at the bottom of any product page. Every “No” goes on the list of what to fix next.

Get Support