Team Banzai · our method · CC BY 4.0

How to audit documentation written by an artificial intelligence

A language model can write a whole manual for a system in minutes. The question isn't whether it reads well: it almost always does. The question is whether it tells the truth about the system in front of it or recites what it knows by heart. These nine checks let you see for yourself, without trusting anyone. They come from the grader we use in the DOOM demo; here they're in plain language, so they work just as well on your ERP's docs.

1. Every claim with a number carries its source.

   A time, a limit, an amount, a rule: next to it, the file and line (or the table, or the contract clause) it comes from. A claim with no source is an opinion, however well written. No citation, doesn't count.

2. You go to the source and check it really says that.

   The step almost nobody takes. It's not enough that a reference exists: open it and see whether the number the docs claim is the one on that line. A citation that points somewhere saying something else is worse than none, because it looks rigorous.

3. You plant a change behind its back and see if it catches it.

   Change a real number in the system without telling it (a deadline, a cap) and ask it to document it. If it reports the new value, it read the system. If it reports the usual one, it's reciting what it already knew. It's the teacher's trick of changing a number in the question to see who copied from the book.

4. The instrument knows how to fail.

   Feed it documentation you know is wrong (that recites the old values) and check that it marks it as bad. A grader that always passes is worthless: if it never gives a zero, a pass means nothing.

5. It declares what it doesn't know.

   Honest docs have a section of doubts: "this depends on the case", "I couldn't check this". The ones that assert everything with the same confidence hide their gaps. Distrust uniform certainty.

6. It tells fixed from variable.

   "Does 7 damage" is different from "does 7, 14 or 21 depending on the case". "Takes 3 seconds" is different from "depends on the distance". If the docs collapse a range or a condition into a single number, they're oversimplifying, and that's an error dressed up as precision.

7. It separates what it read from what it inferred.

   One thing is "the code says 105"; another is "therefore the door waits 3 seconds". The second is a calculation, and calculations get checked. Have the docs mark which are direct facts and which are their own conclusions.

8. It speaks the reader's language.

   The same truth is told differently for whoever maintains the system, whoever decides and whoever uses it. If there's a single doc with jargon for everyone, someone gets left out. Ask for each reader's version, and that the three line up.

9. It's reproducible.

   Another person, with the same system and the same instructions, should reach the same verdict. If the result depends on who's looking or how the wind blew that day, it's not an audit, it's an impression.

The summary in one line: don't ask whether the docs read well; check whether everything they claim is in the system, whether they declare what they don't know, and whether your marker knows how to fail when it should.

Method by Team Banzai (team-banzai.com), published under a CC BY 4.0 licence: use it citing the source. It comes from the tech demo "rebuilding DOOM's documentation by reading its code, exam included".