A volunteer-shift scheduler tester pastes the same user story twice and receives two different case lists. What Chapter 1 explanation fits best?
Select an answer to reveal the explanation.
Short Explanation
Same recipe, slightly different cakes—because the oven samples as it goes. Probabilistic inference can produce different outputs from one unchanged prompt. That is non-determinism, not proof the requirement changed.
Full Explanation
Non-determinism from probabilistic inference can yield different testware from the same prompt. When a volunteer-shift scheduler tester pastes one unchanged user story twice and receives two different case lists, Chapter 1’s explanation is that sampling during generation can vary—not that the civic requirement silently changed between pastes. Teams should plan review, baselining, and suite check-in with that variability in mind rather than chasing phantom scope churn.
Assuming the requirement changed between pastes fails when the stem states the same story was reused. Claiming tokenization randomly deletes half of every second prompt invents a false tokenizer behavior unrelated to generation variance. Claiming embeddings force identical prompts to map to opposite meanings misstates embeddings as semantic vectors and invents an invert-on-rerun switch that is not their definition.
Exam caveat: recognize non-determinism at awareness level for CT-GenAI. Detailed temperature or seed engineering is not required to answer this item, but blaming requirements churn or tokenizer sabotage is wrong.
Operational check: rerun the same scheduler prompt twice under normal settings; if case lists differ, treat it as expected probabilistic variance; lock reviewed cases into version control for the municipal suite rather than re-prompting as the sole source of truth each sprint.