OpenAI Model Spec Explained: System, Developer, User and Tool Hierarchy

Last updated: July 12, 2026 · By Ignacy Kwiecien, founder and editor-in-chief, DecodeTheFuture.org

What is the OpenAI Model Spec?

The OpenAI Model Spec is a public framework that describes intended model behavior across OpenAI products, including the API. It covers instruction following, truthfulness, uncertainty, autonomy, side effects, privacy, sensitive content and default behavior. OpenAI describes it as a living document and says that production models do not yet perfectly reflect every part of it.

This guide was checked on July 12, 2026 against the current Model Spec entry point and the December 18, 2025 versioned edition. The dated page is historical and warns that a newer version is available. It is used here as a precise reference for the hierarchy, not described as the current edition. Check the current entry point before relying on a rule that may have changed.

The Model Spec is different from a hidden system prompt, the OpenAI Usage Policies, a product-specific safety layer, or the training and evaluation stack. It is a public behavioral specification and target, not a transcript of every runtime instruction.

For background on the model layer, see What Is an LLM?. For implementation context, compare this guide with AI agents explained and context engineering.

The OpenAI instruction hierarchy

The December 18, 2025 edition defines five authority levels. Higher authority wins when applicable instructions conflict. The same edition separately classifies some content as having No Authority by default; that classification is not a sixth peer instruction source.

Authority comes from the source and context of an instruction. A tool result can be useful data without becoming a new Developer or User instruction.

Root

Root rules cannot be overridden by system messages, developers or users. They are mostly prohibitive and include boundaries around catastrophic risks, direct physical harm, certain illicit behavior, privacy and attacks on the chain of command. The Model Spec places compliance with applicable laws at the System level, so it is imprecise to describe every law-related rule as Root.

System

System instructions are supplied by OpenAI and can vary by product surface or user context. They sit below Root and above Developer, User and Guideline. An API developer therefore has substantial control, but a developer message is not automatically the highest-priority instruction in the conversation.

Developer

Developer messages define the application’s role and operating rules. Examples include returning JSON, using a billing tool for invoice questions, limiting the assistant to a support workflow, or requiring confirmation before sending an email. Developer instructions cannot override Root or System rules, and they should not grant arbitrary retrieved text the power to rewrite application policy.

User

User messages steer the task, format, language and other preferences inside the higher-level boundaries. If a Developer instruction requires valid JSON and the user asks for prose, the developer format wins. The assistant should still satisfy the compatible part of the user’s request.

Guideline

Guidelines are defaults that can be overridden implicitly by context. A style guideline may favor formal language, but a clear request for a different voice can override it. This flexibility is different from a hard safety boundary and from a Developer contract enforced by application code.

OpenAI Model Spec chain of command: system, developer and user messages

Use this compact process when messages appear to conflict:

1. Identify candidate instructions and separate them from background information, examples and data.
2. Assign each instruction the authority of its source.
3. Remove instructions that conflict with a higher-authority instruction.
4. At the same authority, let a later applicable instruction supersede an earlier one.
5. Follow both the letter and the intended purpose of the surviving instructions.

A small API example

The following is a conceptual message shape, not a copy-paste request. Replace the placeholder with a model ID supported by the account and current OpenAI API reference:

{
  "model": "<verified-model-id>",
  "input": [
    {
      "role": "developer",
      "content": "Return a JSON object with the keys answer and confidence."
    },
    {
      "role": "user",
      "content": "Explain the result in normal prose."
    }
  ]
}

The user still controls the subject, but the developer instruction controls the response contract. Validate the returned JSON in application code; a model-generated object is not authorization to perform an external action.

Tool outputs, files and prompt injection

The Model Spec treats assistant and tool messages, quoted or untrusted text and multimodal data as having no instruction-following authority by default. Content from files and attachments should be treated as untrusted input data unless a higher-level instruction delegates a narrow role to it.

This distinction matters for retrieval and tools:

• A retrieved document can contain facts to summarize without gaining permission to change the assistant’s policy.
• A web page can contain a malicious instruction such as “ignore the developer message”; that sentence is data, not a new authority level.
• A tool can return a status field that the developer explicitly authorized the assistant to inspect, but that does not automatically authorize every sentence in the tool response.
• An image or attachment can be relevant to the task without becoming an instruction to send an email, delete a record or disclose a secret.

Treat prompt injection as an application-security problem. Parse tool results as data, allowlist tools and arguments, enforce authorization on the server, and keep secrets out of prompts and logs. The Model Spec does not make an unsafe tool safe by itself.

For related implementation patterns, see MCP and the Model Context Protocol and prompt engineering.

Model Spec guidance for AI agents and MCP

The Spec’s autonomy and side-effect principles translate into practical controls for an agent:

MCP does not add an authority level to the Model Spec. It is an integration pattern that can expose tools and context; the application still decides which tools exist, what they can do and which user is authorized to call them.

What the Model Spec is not

The Model Spec is not:

• the complete hidden system prompt for ChatGPT;
• a guarantee that every production response follows every rule perfectly;
• a replacement for server-side permissions, tool authorization or product monitoring;
• the same thing as OpenAI Usage Policies;
• a complete description of model training, post-training, runtime routing or product behavior.

OpenAI’s public document is one part of a broader approach that includes policies, evaluations, monitoring and product controls.

Model Spec Evals

OpenAI’s Model Spec Evals page was published March 25, 2026. It describes a dataset of 596 prompts covering 225 concrete focus areas. The published overall compliance figures are 72% for GPT-4o, 80% for OpenAI o3, 82% for GPT-5 Instant, 89% for GPT-5 Thinking, 84% for GPT-5.3 Instant and 87% for GPT-5.4 Thinking.

These are source-reported evaluation results, not a universal product-quality ranking. OpenAI says the current collection covers text-only interactions, is small relative to the breadth of the Spec, and is planned to expand to multimodal interactions, tool use, longer conversations and adversarial settings. The grading system samples five automated scores from 1 to 7 and uses the median; scores of 6 or 7 count as compliant in the published method.

FAQ

Sources

Sources prioritise official OpenAI documentation and distinguish normative Model Spec claims from application-level implementation advice. The versioned Model Spec and Model Spec Evals claims were checked on July 12, 2026.

1. OpenAI, Model Spec current entry point. Current entry point; use it to check later revisions.
2. OpenAI, Model Spec 2025/12/18. Historical reference for the hierarchy and authority rules.
3. OpenAI, Inside our approach to the Model Spec. Scope and intended-behavior context.
4. OpenAI, Usage Policies. Policy distinction.
5. OpenAI Alignment, Introducing Model Spec Evals. Published March 25, 2026; dataset, method, results and limitations.
6. OpenAI, Responses API reference. API message-shape reference.