A credit-union mobile-deposit tester accepts a fluent expected-result paragraph that invents a weekend fee the specification never stated. What Chapter 1 limit does this illustrate?
Select an answer to reveal the explanation.
Short Explanation
A polished story can still get the facts wrong—like a tour guide with a smooth speech and a bad map. Fluent model text is not automatically correct testware. Check it against the specification before you trust it.
Full Explanation
Chapter 1’s core limit for testers is that statistically plausible transformer wording can still be wrong against the test basis, so review remains required. A credit-union mobile-deposit expected-result paragraph that invents a weekend fee never stated in the specification is exactly that failure mode: coherent, professional, and incorrect for civic banking testware.
Tokenization always deleting fees that appear in the specification fails as an explanation—the problem is invented content, not token deletion of real fees. Context windows forbidding money mentions fail as myth; windows budget tokens, they do not ban currency topics. Claims that instruction-tuned models never invent absent details fail because instruction tuning improves following instructions, not perfect factual fidelity to an unstated fee schedule.
Exam caveat: fluency is not verification. Banking and other regulated civic domains make unauthorized invented fees especially dangerous as silent test-basis corruption.
Operational check: diff every generated expected-result claim against the mobile-deposit specification; quarantine any fee, limit, or step absent from the basis; require dual review before the paragraph enters the municipal suite.