On 25 March 2026, OpenAI published a detailed explanation of its Model Spec — the formal behavioural framework that governs how OpenAI’s models should respond, follow instructions, resolve conflicts, and handle edge cases. It is, in effect, a written constitution for AI model behaviour.
For organisations deploying OpenAI models in production, this matters. Not because it changes what the models can do, but because it changes what you can hold the vendor accountable for.
What the Model Spec Actually Is
The Model Spec is not a marketing document. It is a structured specification covering how OpenAI models should behave across a range of scenarios, from routine queries to sensitive edge cases.
It is built around three goals: empower developers and users through iterative deployment, prevent models from causing serious harm, and maintain OpenAI’s operational integrity. These goals are operationalised through a chain of command — a hierarchy that determines whose instructions take priority when conflicts arise between OpenAI’s policies, developer configurations, and user requests.
Hard rules are non-overridable boundaries. These cover catastrophic risks, direct physical harm, legal violations, and attempts to undermine the chain of command. Defaults are overridable starting points — tone, style, and depth settings that developers and users can adjust within safety boundaries.
The Model Spec also includes concrete examples showing compliant and non-compliant model responses, calibrated to illustrate exactly where behavioural boundaries sit. OpenAI has open-sourced the specification and published accompanying Model Spec Evals — a scenario-based evaluation suite that tracks compliance over time.
Why This Matters for Enterprise Governance
Most enterprise AI governance frameworks today are internally focused. They cover data handling, access controls, acceptable use policies, and compliance mapping. What they almost never include is a structured evaluation of the vendor’s own behavioural governance.
The Model Spec gives enterprise technology leaders something they have not had before: a public, versioned, evaluable document against which vendor model behaviour can be assessed. That changes three things.
Auditability improves. When a model produces unexpected behaviour in production, the Model Spec provides a reference document to determine whether that behaviour was intended, a known limitation, or a genuine misalignment. This is materially different from raising a support ticket and waiting for a vague response.
Governance frameworks get a vendor layer. Enterprise AI governance should address both internal controls and vendor controls. The Model Spec gives governance teams a concrete artefact to evaluate as part of vendor risk assessments. Does the vendor’s behavioural framework align with your organisation’s policies? Where are the gaps?
Contractual conversations sharpen. Published behavioural specifications create a baseline for enterprise agreement negotiations. If a vendor publishes specific commitments about model behaviour — such as OpenAI’s commitment to never use system messages to compromise objectivity in first-party deployments — those commitments can be referenced in contracts.
What the Model Spec Does Not Cover
The Model Spec describes intended behaviour, not guaranteed behaviour. OpenAI is explicit about this. Production models do not yet fully reflect the specification — training can lag behind updates, generalisation can differ from intent, and the long tail of real-world usage will always surface edge cases not covered by any document.
The specification also covers the model, not the product. Broader system-level features, monitoring, policy enforcement, and product design sit outside the Model Spec’s scope. Safety, as OpenAI acknowledges, is about defence in depth — not a single document.
For enterprise governance purposes, this means the Model Spec is a necessary but not sufficient input into vendor risk assessment. It raises the floor for transparency but does not eliminate the need for independent evaluation, testing, and monitoring.
Aligning with Australian Governance Requirements
For Australian organisations operating under the Essential 8 framework and ACSC guidance, the Model Spec maps to several existing governance domains.
Access control principles in the Model Spec — particularly the least-privilege design for developer and user overrides — align with Essential 8 controls around restricting administrative privileges and application control. The chain of command concept provides a structured model for how AI system permissions should be scoped.
The specification’s emphasis on continuous evaluation and monitoring aligns with the ACSC’s push for ongoing security assessment rather than point-in-time compliance checks. Organisations can use the Model Spec as a reference point when designing their own AI monitoring and audit processes.
Three Steps for Incorporating Vendor Behavioural Specs into Governance
Review the Model Spec against your AI acceptable use policy. Identify areas where the vendor’s behavioural framework supports your internal policies and areas where it creates gaps. Pay particular attention to how the chain of command interacts with your developer and user permission structures.
Add vendor governance to your AI risk register. If your organisation maintains a risk register for AI deployments, include vendor behavioural governance as a distinct risk category. Track whether vendors publish and maintain behavioural specifications, whether those specifications are versioned, and whether evaluation data is available.
Engage your vendor on governance alignment. Use the Model Spec as a starting point for conversations with your AI vendor representatives about how behavioural governance is maintained, how incidents are surfaced, and what commitments can be formalised in enterprise agreements.
The Governance Bar Is Rising
The publication of the Model Spec signals that AI vendors are beginning to treat behavioural governance as a competitive differentiator. Anthropic publishes its own constitution and Responsible Scaling Policy. OpenAI now has the Model Spec. These are not just safety documents — they are governance artefacts that enterprise buyers should evaluate with the same rigour applied to SLAs and security certifications.
Our team advises Australian mid-market organisations on integrating vendor governance evaluation into their AI risk management frameworks. If your organisation is deploying OpenAI or other AI models and your governance framework does not yet account for vendor-side behavioural specifications, we would welcome the conversation.