A farmers-market stall-lottery tester receives a chatty paragraph when the suite needs a three-column case table. Which prompt component defines the expected format, structure, or characteristics of the response?
Select an answer to reveal the explanation.
Short Explanation
Output format is the mold the answer must pour into. If the suite needs a three-column table and the prompt never says so, a chatty paragraph is unsurprising. Input data is what you feed in; output format is how the reply should look.
Full Explanation
Output format defines the expected format, structure, or characteristics of the response—such as a three-column case table the farmers-market stall-lottery suite can ingest. When the tester receives a chatty paragraph instead, the missing or weak Output format component is the usual cause: the model was never told the shape the pipeline expects. Civic automation downstream needs structured testware, not essays that humans must retype by hand.
Input data are the lottery story or existing case sheet attached; they ground content but do not by themselves force a three-column table. Instruction requests drafting stall-lottery test cases but may omit structure. Context explains how the farmers-market lottery works without specifying reply shape.
Exam caveat: Output format is a first-class structure component. Task clarity without shape still yields unusable prose for many municipal import paths and CI fixtures.
Operational check: specify columns (for example id, precondition, steps) explicitly in Output format; regenerate; validate the table parses into the stall-lottery tool; reject narrative-only replies for suite import and update the prompt gate so shape is mandatory. In municipal lottery operations, treat Output format as a release gate equal to content review so chatty paragraphs never enter the automation queue.