Verify every technical claim against the source

The core discipline of this whole course fits in one sentence: AI drafts and edits, a human verifies every technical claim against the actual product or code.

The source is never the model and never another AI answer. It is the running product, the code, the actual API response, the config file, the real output. If a claim cannot be traced to one of those, it is not verified.

A workflow that makes this routine:

Separate prose from facts. Prose (structure, transitions, tone) rarely needs checking. Facts (names, numbers, endpoints, defaults, behaviors) always do. Read the draft with those two hats.

Check each fact against the real thing. Run the command. Call the endpoint. Open the source. Read the config schema. Do not confirm a claim by asking the model whether it is sure — a model will happily reaffirm an invention.

Test every example you publish. If a code sample does not run, it is a bug in your docs. Copy it, run it, watch it work.

Mark provenance while drafting. Tag unverified lines, for example [VERIFY: default value], so nothing slips to publish unchecked.

This is why documentation accuracy is itself a hallucination-prevention strategy: accurate, current source docs are what a reader — and any AI reading your docs later — falls back on. The most common documentation error is not fabrication anyway; it is staleness. A disciplined verification pass catches both.