The dominant defect in LLM-written technical prose is a lost qualification, not a false statement

Audited 204 machine-written technical notes against the sources they were derived from. Five real factual errors reached a shipped artifact. The striking thing is what they had in common: NONE of them contained a false string. Every one was text more confident than its evidence supported.

The five, by shape: - a plausible-looking API identifier camel-cased into a variant that does not exist (an error-enum member name). Made skim-proof because a CORRECT identifier sat in the same sentence. Fails only at compile time. - a rule stated without its exception (a minimum-balance rule, omitting that going to exactly zero is the legal way to close the thing). - a naming convention asserted flatly where the truth is version-dependent. The source hedged "this changed across versions, read the generated file"; the note dropped the hedge. - an invented lookup order presenting a path as a default search location, when that path only works because a build tool happens to set an env var to it - a different mechanism entirely. - a promised symptom direction the source never gave: "every test passes against the stale binary". In the common case tests FAIL, so the claim would make a reader rule the true cause out precisely when it applies. Note this one appeared in a CORRECTION written by a reviewer, not in the original.

Why this class survives review: 1. Every structural/lint gate passes it. There is no malformed field, no missing citation, no broken link, no invalid enum. Schema validation is blind to it by construction. 2. Reviewers instructed to check CLAIMS against the source skim past it, because the claim is true - it is the missing qualifier that is wrong. You have to diff the HEDGES, not the assertions. Concretely: for every unconditional statement in the generated text, find the corresponding sentence in the source and ask whether the source conditioned it on a version, a configuration, or an exception. 3. It reads better than the source. Removing "usually", "as of version X", "in my case" makes prose crisper, so a fluency-oriented generator is actively selected toward producing it.

What actually catches it: a second independent reviewer. Measured on the one item read by two reviewers, each found a different factual defect and neither found both - so a single reviewer should be assumed to catch roughly half. Redundancy beat depth here, and it is the only intervention that addressed this class at all; a stricter schema would have caught none of the five.

Corollary for prompts: asking a generator to be "self-contained and confident" trades directly against this. Better to require version context explicitly and to instruct that uncertainty be stated in one clause rather than dropped.