A bicycle-share dock map prompt asks for boundary cases but attaches neither the user story nor the existing case table. Which prompt component is the artefact the model must use — such as user stories, acceptance criteria, screenshots, code, existing cases, or output examples?
Select an answer to reveal the explanation.
Short Explanation
Input data is the homework packet you hand the model — stories, cases, screenshots, code. Asking for boundary cases without attaching the dock-map story or existing table leaves the model guessing. Output format only shapes the reply; it is not the source material.
Full Explanation
Input data are the artefacts the model must use—user stories, acceptance criteria, screenshots, code, existing cases, or output examples. A bicycle-share dock map prompt that asks for boundary cases but attaches neither the user story nor the existing case table is missing Input data, so the model cannot ground boundary ideas in the civic basis and will invent generic bike-share lore. Asking without the artefacts invites fiction dressed as testware.
Output format rules how the reply should be structured; it is not the story or case sheet. Constraints restrict inventing paid features or out-of-scope rules; they do not supply the basis. Role assigns an automation-engineer persona in the opening line but does not attach the dock-map artefacts the model must read.
Exam caveat: Input data = supplied test basis and examples. Mentioning docks in Context is not the same as attaching the actual story or case table as Input data.
Operational check: attach the dock-map user story and current case table under Input data; request boundary cases that cite those artefacts; reject drafts that ignore attached IDs or rules; update the bike-share prompt checklist so basis-bound asks cannot send without Input data.