Meridian Line's charter-desk assistant must always answer as a contracts analyst, always cite clause numbers, and always decline questions about crew disciplinary matters. Developers keep forgetting to include these rules and users can talk the model out of them mid-conversation. Where do these rules belong?
Select an answer to reveal the explanation.
Short Explanation
The system prompt is your standing order; the user turn is a request. Put persistent identity, format rules, and refusal scope in the system prompt your application controls, so users cannot edit them and later turns cannot quietly drop them.
Full Explanation
Place these rules in the system prompt, which the application supplies for every request. That keeps the contracts-analyst role, clause-citation requirement, and refusal scope in force across turns and outside the end user’s control. Appending them to each user message may make them recent in the model’s attention, but it mixes application policy with user-authored text: a user can contradict the rules, and the front end must maintain policy it should not own. Retrieved context is evidence from a corpus, not a policy channel; it competes with evidence for space, and mixing instructions with documents creates the confusion prompt-injection defenses seek to prevent. Putting the rules only in the first user turn is also unreliable: the model has no memory beyond messages resent on each call, so that turn persists only if the application keeps sending it, and its influence can fade as history grows. Exam caveat: a rule stated once is not guaranteed to remain effective merely because it appeared early in the conversation. Practical check: inspect each request your application sends and confirm the system prompt contains the rules; a short restatement of the output format near the user question can reinforce formatting without replacing that policy source.