When errors sit inside correct content, checking is sentence by sentence and costs about as much as rewriting

What it is

A product write-up: nine paragraphs of mechanism are right; mid-third names a competitor’s discontinued model. Spot-checking the opening and the close will miss it; a read that “feels fine” will miss it. The error is not a false document; it is one sentence nested in true ones. Scattered-error checking means verification has to run sentence by sentence — and the cost then approaches rewriting the whole, because every sentence might be the grain of sand.

Whether the labour of the whole task still pays is a different ledger. This entry is how the spatial distribution of error forces a full scan.

Why it happens

Human checking defaults to sampling: read the opening, scan headings, pull a number or two. That strategy assumes errors cluster, or that they wreck global coherence. Generated errors often refuse that assumption: local coherence still holds, and what is wrong is one slot (a model name, a dose, a clause number). Expected detection under sampling falls as errors spread; to hold miss rate down, sampling has to densify toward exhaustive check.

Exhaustive check has none of the writer’s generative memory; every sentence is a new judgment. “Mostly right” therefore does not cut cost — it raises misses: correct sentences wear down vigilance, and the next wrong one is less likely to be treated as a suspect.

Studying it

Build texts with a fixed error rate (say 5% of fact slots); manipulate clustered versus uniformly scattered. Allow spot checks or require sentence-by-sentence. Dependent variables: miss rate, checking time, self-reported confidence. Independent variables: clustering of errors, whether correct sentences are highly fluent, whether a sentence-level check UI is provided.

Report confidence × misses. Scattered conditions often show high confidence and high misses — the signature of a sampling strategy fooled by “mostly right.”

Where it stops holding

If an error wrecks global structure (sections that do not match, a table that does not sum), sampling can find it and sentence-by-sentence is unnecessary. Machine-checkable slots (a model against a catalogue, a checksum, a compile) can take the exhaustive pass; people only see the sentences the program marked. Pure stylistic polish has almost no fact slots; sentence-level fact checking is the wrong tool. Very short text (two or three sentences) is already the exhaustive window; scatter does not apply. This entry does not treat checkers who lack domain knowledge and cannot see the error at all.

Applying it

• Offer sentence- or field-level checking for fact slots. Do not offer only “does the whole thing look reasonable.”
• Auto-mark machine-comparable slots (model names, clause numbers, amounts, dates) as to-check, rather than burying them in a paragraph for sampling.
• Do not use “overall accuracy is high” as a reason to spot-check. High accuracy plus scattered error is when spot-checking is worst.
• Check: on a text that is 95% correct with errors buried uniformly, let target users check as they normally would, then compare sentence by sentence to a gold standard. Every miss means sampling was already insufficient and the interface has not taken checking down to the field.

Related

• Same group: L3.03.1 Fluent wording is not the same as being correct · L3.03.2 The cost of checking can exceed doing the work oneself · L3.03.3 High-stakes settings must not leave checking entirely to the user · L3.03.5 The less familiar the domain, the harder checking is — and that is exactly when people ask the system · L3.03.6 Certainty of wording has no relation to reliability of content · L3.03.7 Errors in numbers, dates, and names are the hardest to notice and the most damaging · L3.03.8 Putting the checking duty in a disclaimer does not reduce how far errors actually spread
• Nearby: L3.02 Source Attribution · L3.08 Source Attribution of Generated Results
• Search terms: scattered-error checking · sentence-level verification · mixed correct and false