OpenAI has done something unusual for a company often criticised for opacity: it published a detailed, versioned specification for how its AI models should behave, then open-sourced it on GitHub for anyone to read, critique, and propose changes to. The Model Spec is not a marketing document or a set of vague principles. It is a structured governance framework that defines instruction hierarchies, conflict resolution rules, safety boundaries, and behavioural defaults — and it has direct implications for how every organisation building or deploying AI should think about governance.
Why a behavioural specification matters more than principles
Most organisations approach AI governance with broad value statements: “be ethical,” “be transparent,” “avoid bias.” These read well in board presentations but collapse under operational pressure. When a developer needs to decide whether a model should refuse a particular request, or how to handle conflicting instructions from different stakeholders, principles alone offer no guidance.
OpenAI’s Model Spec addresses this gap directly. It operates at the level of concrete decision rules rather than aspirational statements. The document specifies how models should resolve conflicts between operator instructions and user requests, what constitutes an unoverridable safety boundary versus an adjustable default, and how the system should handle ambiguity in agentic contexts where models act with greater autonomy.
Strategic Insight: The shift from principles to specifications mirrors what happened in software engineering decades ago. Vague requirements produce unreliable software. Precise specifications produce testable, improvable systems. AI governance is following the same path.
This distinction matters for UK organisations subject to evolving regulatory frameworks. The EU AI Act and the UK’s own pro-innovation approach both require demonstrable governance — not just stated intentions. A behavioural specification gives regulators something concrete to evaluate and gives internal teams something concrete to build against.
The chain of command: a model for organisational AI decision-making
The most operationally useful concept in the Model Spec is what OpenAI calls the “chain of command.” Instructions flow from multiple sources — OpenAI itself, third-party developers using the API, and end users — and these instructions can conflict. The chain of command defines a priority system for resolving those conflicts.
At the top sit hard rules: explicit boundaries that no user or developer can override. These address catastrophic risks, direct physical harm, and legal violations. Below these sit defaults — overridable starting points that define predictable behaviour when no specific instruction has been given. Defaults split further into user-level anchors (like truthfulness) that require explicit instructions to change, and guideline-level preferences (like tone) that can shift implicitly.
| Authority level | What it covers | Can it be overridden? | Example |
|---|---|---|---|
| Hard rules (root/system) | Catastrophic risks, legal violations, physical harm | No | Refusing to help create weapons |
| User-level defaults | Truthfulness, objectivity, honesty norms | Only by explicit instruction | Maintaining factual accuracy even when user implies a preference |
| Guideline-level defaults | Tone, style, format, depth | Yes, implicitly or explicitly | Adjusting formality based on conversation context |
| Developer instructions | API system prompts, custom configurations | Yes, within safety boundaries | A customer service bot’s persona and scope |
| User requests | Individual conversation instructions | Yes, within all higher constraints | Asking for a specific output format |
Critical Context: This hierarchy is not just a model safety feature. It is a governance architecture. Any organisation deploying AI internally — from customer service chatbots to code generation tools — faces the same structural question: who gets to override whom, and under what conditions?
For UK businesses, this framework maps directly onto questions that the Information Commissioner’s Office and sector regulators will increasingly ask. Who decided the AI should behave this way? Where is that decision documented? What happens when the system receives conflicting guidance? The chain of command provides a template for answering these questions.
What the compliance chart actually tells us
OpenAI published compliance data showing how well its models follow the Model Spec across five categories: chain of command, staying in bounds, seeking truth, doing best work, and using appropriate style. The results show steady improvement across model generations, with GPT-5.4 Thinking (March 2026) achieving the highest compliance scores.
Three observations stand out from this data:
Compliance is measurable when specifications are precise enough. The fact that OpenAI can score its models against the Spec demonstrates that behavioural governance need not remain subjective. Organisations that write vague AI policies cannot measure compliance with them. Organisations that write precise specifications can.
No model achieves perfect compliance. Even GPT-5.4 Thinking, OpenAI’s most recent model, shows measurable gaps. OpenAI acknowledges this directly: training lags behind specification updates, training can inadvertently teach inconsistent behaviour, and generalisation can differ from intent. This honest framing is more useful than any claim of perfection.
The gap between specification and behaviour is itself the governance mechanism. Rather than pretending models behave perfectly, the Model Spec creates a measurable distance between intended and actual behaviour. That distance becomes the basis for improvement, accountability, and public scrutiny.
Reality Check: If OpenAI — with thousands of researchers and billions in compute — cannot achieve full compliance with its own behavioural specification, smaller organisations should plan for the same gap. The value is not in perfection but in making the gap visible and systematically reducing it.
Hard rules versus defaults: getting the boundary right
One of the most consequential design decisions in the Model Spec is where to draw the line between hard rules and defaults. Get this wrong in either direction and the system fails.
Too many hard rules and the system becomes rigid, paternalistic, and unable to serve the diverse needs of its users. OpenAI explicitly acknowledges this tension: “We expect AI to become a foundational technology for society, analogous to basic internet infrastructure, so we only impose rules that could limit intellectual freedom when we believe they are necessary.” This is a deliberate choice to keep the unoverridable set small.
Too few hard rules and the system becomes a tool that can be steered toward harmful outcomes by anyone with the right prompt. The Model Spec draws this line at catastrophic risks, direct physical harm, legal violations, and undermining the chain of command itself.
Strategic Reality: The hard rules versus defaults distinction is the most transferable concept in the entire Model Spec. Every organisation deploying AI needs to answer this question: what is absolutely non-negotiable, and what can users and operators adjust? Most organisations have not made this distinction explicit, which means they have neither meaningful safety boundaries nor meaningful flexibility.
The defaults system deserves particular attention. OpenAI distinguishes between defaults that anchor trust (truthfulness, objectivity) and defaults that enable customisation (tone, style). The trust anchors require explicit instruction to change — a user cannot accidentally or implicitly shift the model away from honest responses. Style defaults, by contrast, shift naturally based on context.
This two-tier default system solves a problem that plagues enterprise AI deployments: the tension between consistency and adaptability. Fixed behaviour annoys users who need flexibility. Fully flexible behaviour creates unpredictability and risk. The two-tier approach preserves both.
The constitution analogy and its limits
OpenAI draws a deliberate comparison between the Model Spec and a written constitution. High-level principles provide a foundation, but real governance requires interpretive machinery — clarifications, worked examples, and explicit rulings for edge cases. The Model Spec includes decision rubrics for grey areas and concrete examples showing compliant and non-compliant responses to the same prompt.
This analogy is useful but incomplete. Constitutions operate within democratic systems that include independent courts, legislative processes, and mechanisms for public challenge. The Model Spec, by contrast, is ultimately governed by OpenAI. The company makes the final decisions about what goes in, what changes, and how conflicts are resolved.
Hidden Cost: The governance gap between the Model Spec’s constitutional aspirations and its corporate reality is worth watching. OpenAI has invested in collective alignment mechanisms and public feedback processes, but these remain advisory rather than binding. For organisations relying on OpenAI’s models, this means the behavioural framework can change based on OpenAI’s commercial or strategic priorities, not just public input.
OpenAI does acknowledge this limitation indirectly. The document states that “benefiting humanity is OpenAI’s goal, not a goal we want our models to pursue autonomously.” The company positions itself as the authority within the chain of command, with models following instructions rather than making independent ethical judgements. This is a defensible position — autonomous moral reasoning in AI systems raises its own serious risks — but it concentrates significant power in one organisation.
Building your own behavioural specification
The Model Spec’s greatest value for most UK organisations is not as a document to adopt wholesale but as a structural template for building their own governance frameworks. Here is a practical implementation path:
For organisations just beginning AI governance:
Start by documenting your hard rules. What must your AI systems never do, regardless of who asks? For a financial services firm, this might include never providing personalised investment advice without appropriate disclaimers. For a healthcare provider, never diagnosing conditions. For any UK organisation, never processing personal data in ways that violate UK GDPR. Write these down. Make them specific. Make them testable.
For organisations with existing AI policies:
Audit whether your policies distinguish between hard rules and defaults. Most do not. Convert your existing guidance into the two-tier structure: non-overridable boundaries and adjustable starting points. Then identify which defaults anchor trust (and should require explicit override) versus which enable customisation (and can shift implicitly).
For organisations deploying AI at scale:
Build evaluation suites against your specification, following OpenAI’s approach with Model Spec Evals. Measure compliance. Report the gaps honestly. Use the gap between specification and behaviour as your primary governance metric. This is far more actionable than annual AI ethics reviews or periodic policy updates.
Take Action: Start with a single-page document listing your five non-negotiable AI behaviours and your ten adjustable defaults. Test it against three real scenarios your team has encountered. If it does not give clear guidance for all three, it is not precise enough.
Four challenges the Model Spec does not solve
The vendor lock-in problem. If your AI governance is built on top of OpenAI’s Model Spec, you inherit their decisions about what is and is not acceptable. Switching to Anthropic, Google, or an open-source model means rebuilding your governance assumptions. The solution is to write your own specification first, then map it onto vendor capabilities — not the other way around.
The measurement gap for custom deployments. OpenAI can measure Model Spec compliance because it controls the training process. Organisations using the API through custom applications have far less visibility into whether the model is actually following the specification in their specific context. System prompts help but are not equivalent to training-level enforcement.
Warning: ⚠️ Do not confuse a vendor’s published governance framework with governance of your own AI deployment. The Model Spec governs OpenAI’s models. Your deployment context, user base, regulatory obligations, and risk profile require your own specification layered on top.
The evolution problem. The Model Spec is a living document that changes as OpenAI learns from deployment. This is good for improvement but creates a compliance tracking challenge. Organisations building on OpenAI’s API need to monitor Spec changes and assess whether those changes affect their own governance assumptions.
The agentic frontier. As AI systems become more autonomous — booking flights, writing code, managing workflows — the governance challenge shifts from “what should the model say” to “what should the model do.” The Model Spec addresses this with guidance on controlling side effects and scoping autonomy, but this remains the least mature area of the framework. Organisations deploying agentic AI need to supplement the Model Spec with their own operational controls.
What to take from this
OpenAI’s Model Spec represents the most detailed public attempt at AI behavioural governance to date. Its value is not in the specific rules — many of which are particular to OpenAI’s products — but in three structural innovations:
- The chain of command gives organisations a template for resolving conflicting instructions in AI systems, with clear authority levels and override rules
- The hard rules versus defaults distinction provides a practical framework for balancing safety with flexibility, solving the rigidity-versus-risk problem that most AI deployments face
- The specification-as-governance approach makes AI behaviour measurable, auditable, and improvable — moving beyond principles-based governance to something that can actually be tested
Next steps for UK AI leaders:
- Audit your current AI governance for the principles-versus-specification gap. If your governance documents contain words like “should strive to” but not “must never,” you have a specification problem
- Draft a chain of command for your AI deployments. Who can override whom? Document it
- Identify your hard rules — the five to ten behaviours that are non-negotiable regardless of user or operator instructions
- Build at least one evaluation scenario for each hard rule. If you cannot test it, you cannot govern it
- Review the full Model Spec and the Model Spec Evals for structural inspiration
Source: “Inside our approach to the Model Spec,” OpenAI, 25 March 2026. Author: Jason Wolfe.
Analysis by Resultsense — making sense of AI in the UK.