Message Role Hierarchy

Overview

Chat-style APIs assign every message a role, and roles form a priority chain: developer > user > assistant. When instructions in different roles conflict, the higher-priority role wins. This is the API-level articulation of the “system prompt beats the user” principle: the developer’s message defines the rules of the conversation, the user’s message states the goal, and the assistant’s own prior output is the lowest-priority signal.

Role Priority Chain (confidence: high)

Priority	Role	Role
1 (highest)	developer	System-level instructions; defines behavior and rules
2	user	The task or question; may instruct but cannot override developer rules
3 (lowest)	assistant	The model’s own generated output; treated as provisional

The instructions Parameter (confidence: high)

On the Responses API, the instructions parameter is the developer-level message. It takes precedence over input and applies only to the current generation — it is not persisted in conversation state the way input history is. Practical consequences:

• Put durable behavioral rules in instructions, not buried in input.
• Re-send instructions on every call where the rules must hold; do not rely on the model remembering them across calls.
• User/assistant content can never silently weaken developer-level rules.

Developer Message Structure (confidence: high)

The guide recommends a developer message organized into labeled sections, formatted with Markdown + XML tags:

• Identity — who the model is.
• Instructions — what to do (and not do).
• Examples — few-shot demonstrations of desired output.
• Context — background material (optionally retrieved via RAG).

This mirrors the markdown-header-format and xml-envelope-format envelope patterns this wiki documents elsewhere: labeled sections make instructions locatable and testable rather than a wall of prose.

Implications

The role hierarchy is a control architecture, not a formatting nicety: it gives the developer a priority-resolved way to state rules, and it warns against trusting assistant context as high-authority. Combined with the instructions-applies-to-current-generation rule, it implies prompts must be re-stated per generation — a page cached once is not a guarantee of behavior on the next call. This connects directly to structured-outputs (contracts) and reasoning-effort (inference-level control) as the modern OpenAI control surface.

Open Questions

• How the developer role interacts with tool-result messages (which role should tool output claim?) — the guide does not specify.
• Whether the priority chain holds identically in Chat Completions, where the same concept appears as a system role.

Related

• gpt-5-6 — the model family the guide’s examples use
• structured-outputs — schema contracts as a complement to role-based control
• markdown-header-format — sectioned prompt structure (Markdown)
• xml-envelope-format — sectioned prompt structure (XML)
• prompt-engineering-guides — official OpenAI practical guides, including this one

Sources