System instructions versus user prompts: separate stable rules from current material
Explain the roles of system-level requirements and individual task input, organize multi-turn history, retrieved material and template variables, and test rules with conflicting examples.
Choose an approach
Place stable roles and requirements in the interface’s system or developer instruction field, and current questions and source material in user input. Fields and priorities differ by platform; writing “system instruction” in ordinary text does not increase its authority. Reusable tasks should clearly separate fixed rules from replaceable material.
Interface roles and text labels are not equivalent
OpenAI’s prompt-engineering guide distinguishes message roles and instruction requirements; Anthropic also explains system-role configuration. Use actual interface fields. Giving text a prominent heading does not automatically elevate it above the message containing it.
Source material can contain someone else’s commands, such as an email requesting attachment forwarding. For a summarization task, those commands are content to analyze. Mark source boundaries and restrict tools in the application; one system instruction does not prove external text has no influence.
Check fixed requirements against the same task
Extract fields from one product description with a stable rule against filling missing facts. Test complete material and a version missing its date. If output language changes for this task, make it a task parameter rather than writing conflicting instructions in several places.
For multi-turn calls, confirm that fixed instructions actually remain in the request. Conversation references and per-request instructions can behave differently. Save the request structure and recheck earlier agreements when continuing the task. This is a proposed validation, not a test performed here.
Control variables and scope when maintaining templates
Version fixed instructions separately and replay old inputs after changes. If users can replace template variables, avoid inserting their contents directly into tool configuration. Handle material and permissions separately so changes can be attributed to input or rules instead of adding more emphasis.
Longer rules are not necessarily better. Remove conflicting or outdated requirements, retain necessary conditions and allow an explicit unknown response. Check fields against sources; a model’s statement that it complied is not acceptance evidence. No product’s instruction-defense success rate was tested here.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.