Prompt structure and instruction design

An effective prompt makes the task explicit. Separate system-level behavior from the user request, provide relevant context, define constraints, and show the expected output shape. Place untrusted input in a clearly delimited region and tell the model how to use it. Avoid contradictory instructions and unnecessary background that consumes context without improving the answer. Prompts are application artifacts: version them, review changes, and run the same evaluation set after editing. Examples can clarify a desired classification or style, but they also bias behavior, so include representative and edge cases. Do not treat a prompt as an authorization boundary or a substitute for validating model output. A prompt template should make the boundary between trusted instructions and untrusted content obvious. State the task, the permitted evidence, the desired response format, and an explicit fallback when evidence is insufficient. Keep reusable instructions separate from per-request data, and avoid placing secrets or unnecessary personal information in the prompt. When changing a template, compare the new version with a saved baseline on the same cases, including injection attempts and ambiguous requests. Prompts influence model behavior but do not enforce access control; validate outputs and authorize every consequential action in application code. Implementation drill: trace one representative request through the stages in the diagram. Write down what enters each stage, what output or evidence it produces, and which identity is allowed to perform it. Then test an empty input, an unauthorized request, a dependency timeout, and an unexpected result. For each case, state whether the application should retry, reject, abstain, or ask a person for help. Keep the observed failure as a regression example so changes to prompts, models, data, or code can be checked against the same behavior. Practice task: What should an application do with text retrieved from an external source?