OpenAI's new Model Spec: what it changes for teams building on LLMs, and what it does not

What changed

OpenAI published an updated Model Spec on 29 October 2026¹. It is reorganised around five values: faithfulness to human intent, harm minimisation, honesty and transparency, human agency, and care¹³. Most detailed guidance on writing style was retired, with style expected to follow user preferences and context⁴. The Spec includes an updated chain of command describing which instructions apply and how conflicts are resolved, with sections marked at different levels of authority², and a new section on how memories and earlier conversations should inform the model's reading of what people want².

Two caveats matter. OpenAI describes the Spec as a target, and says its models do not yet fully reflect it⁵. And secondary coverage differs on some details of how developer and user instructions are ranked³, so read the primary text for anything you depend on.

Why it matters if you build on these models

A model's published behaviour rules are a moving part of your system. When they change, three things can change with them: how the model resolves conflicts between your system prompt and user requests, how it treats context such as memory and retrieved documents, and how it styles its output. None of that shows up as an API change, so it will not break your build. It can still break your product.

Five things to do

1. Treat the Spec as context, not a control. A vendor's behaviour document describes intent. It does not replace your own guardrails for data access, consequential actions or regulated decisions. See policy layers for AI assistants.
2. Write system prompts that state scope and priorities explicitly. Do not rely on the model to infer that your instructions outrank user requests. Say what the assistant is for, what it must refuse, and what to do when a user asks for something outside scope.
3. Keep untrusted content in its place. Retrieved documents, tool results and emails should be clearly marked as data, and actions that matter should go through checks outside the model. See prompt-injection defence for agents.
4. Specify style instead of relying on defaults. With detailed style rules retired from the Spec⁴, house style should live in your prompts and be checked by your evaluations, especially for customer-facing text.
5. Re-run your evaluation set when the model or Spec changes. Behaviour will drift as models are trained towards the new Spec⁵. Pin model versions where you can, and compare results before upgrading. See evaluation sets that predict production.

Know which model answered

When behaviour changes, the first question is always which model, at which version, produced the output. The OpenTelemetry generative AI conventions record the requested model and the model version that actually responded on every call, alongside token usage⁶. With that in your traces, a shift in behaviour can be tied to a model update rather than guessed at.

A routine for every model change

CTO take

Publishing a detailed Model Spec is useful transparency, and the explicit chain of command will help teams reason about conflicts between their instructions and users'. But the Spec is a statement of intent about a moving target. Teams that ship reliable AI products own their behaviour: explicit prompts, independent controls, evaluations that run on every change and telemetry that names the model behind every answer. Do that, and a vendor's Spec update becomes a routine regression run rather than a production surprise. For the wider week, see the 31 October tech news brief.

How I can help

I help teams set up model governance: prompt and policy design, evaluation suites and upgrade routines across vendors. I am based in India, the United States and the UAE, working globally. See AI architecture or analyse your challenge and bring the result to a call.