CHAPTERS
Why “Model Spec” matters for builders and users
Host Andrew Mayne sets the stage with alignment researcher Jason Wolfe: the Model Spec is meant to shape and explain how OpenAI models should behave. They frame the conversation around practical impact for anyone deploying or relying on AI tools.
- •Episode goal: demystify the Model Spec and its role in model behavior
- •Alignment focus: models should reason through hard problems rather than jump to answers
- •Importance for developers and everyday users interacting with AI systems
Defining the Model Spec: what it is—and what it isn’t
Jason explains the Model Spec as a human-readable description of high-level behavior decisions for OpenAI models. He emphasizes boundaries: it’s not a claim of perfect compliance, not a training/implementation document, and not a complete map of the entire product stack.
- •Spec describes intended behavior across many dimensions (helpfulness, safety, style, etc.)
- •Not a guarantee that models follow it perfectly; alignment is iterative
- •Not an implementation artifact; primary audience is humans (public, developers, policymakers)
- •Not the full ChatGPT system: product features and policy enforcement also matter
- •Focus is on key decisions, not exhaustive rules for every scenario
How the spec works in practice: structure, rules vs defaults, and examples
They walk through how the document is organized: goals up front, then detailed behavioral policies. Jason highlights the mix of hard constraints (non-overridable) and steerable defaults (tone/style), and why concrete examples are essential to clarify decision boundaries.
- •Long-form document (on the order of ~100 pages) with goals and detailed policies
- •Hard rules vs steerable defaults (tone, personality) to preserve customization
- •Examples used to clarify borderline cases (e.g., honesty vs politeness)
- •Examples also communicate “how to speak,” not just what to do
- •Policy coverage is broad because users can ask “literally anything”
Transparency and public input: where to read it and how feedback flows in
Jason points listeners to the public Model Spec website and the open-source repository. He describes feedback channels—product feedback and direct outreach—and notes that public input has influenced real revisions over time.
- •Read the latest spec at model-spec.openai.com
- •Source is on GitHub and is open source (can be forked)
- •Feedback via in-product thumbs/ratings and other channels (including direct messages)
- •Spec changes have been driven by user/community feedback
- •Transparency is positioned as core to trust and accountability
Origins: from RLHF limits to a “handbook” for increasingly capable models
Jason explains the motivation: RLHF data is hard to interpret and hard to update when goals change. As models get smarter, a more explicit “employee handbook” approach becomes attractive; the project formally began in 2024 and was made public for transparency.
- •RLHF can encode policies but is opaque and difficult to modify retroactively
- •Vision: as models advance, teach them like humans—through explicit written guidance
- •Model Spec project started in 2024 (led by Joanne Jiang and John Schulman)
- •Jason joined early and helped write the initial version
- •Public release was a deliberate transparency choice
From document to behavior: training links, deliberative alignment, and complexity
They discuss how written policy becomes model behavior, noting it’s not a simple one-to-one pipeline. Some training (e.g., deliberative alignment for reasoning models) directly draws on spec language, but often the spec tracks and clarifies evolving intentions rather than dictating every training change.
- •Spec-to-model translation is indirect and technically complex
- •Deliberative alignment helps reasoning models follow explicit policies
- •Sometimes training changes first, then the spec is updated to reflect intent
- •Many specialized techniques are used across different principles
- •Safety/alignment work is distributed across large research teams
Chain of command: resolving conflicting instructions and preserving steerability
Jason introduces the Model Spec’s core mechanism for conflicts: the chain of command. It prioritizes OpenAI-level constraints over developer instructions over user requests, while placing many policies at low authority levels so users can still steer behavior whenever safety boundaries aren’t at stake.
- •Conflicts arise between OpenAI policies, developer prompts, and user instructions
- •Priority order: OpenAI instructions > developer instructions > user instructions
- •Policies are assigned authority levels to determine when they can be overridden
- •Design goal: keep most policies below the user level to maximize steerability
- •Only a small set of high-authority policies remain (primarily safety-critical)
Edge cases under uncertainty: Santa Claus, “don’t lie,” and nuanced honesty
A child asking about Santa becomes a case study in uncertainty: the model often can’t know who’s asking or who is listening. Jason explains the approach: avoid direct deception while also avoiding needlessly “spoiling the magic,” illustrating how honesty can require nuance in real-world contexts.
- •Models lack key context (age, intent, audience), so policies must handle uncertainty
- •Conservative assumption: a kid might be asking or listening
- •Balance: avoid lying but also avoid ruining childhood myths unnecessarily
- •Spec includes similar examples (e.g., Tooth Fairy) to guide behavior
- •Honesty interacts with other values like friendliness and user experience
Policy interactions can backfire: confidentiality vs honesty and avoiding “covert” behavior
Jason describes a surprising failure mode: emphasizing confidentiality of developer instructions can combine with other goals to produce undesirable behavior, like covertly pursuing developer intent against the user. OpenAI adjusted the spec to prioritize honesty above confidentiality to prevent these dynamics.
- •Earlier spec versions treated developer instructions as confidential by default
- •Risk: models might hide developer intent while still pursuing it against user wishes
- •Even controlled demonstrations exposed this “covert conflict” failure mode
- •Spec revised to reduce exceptions and place honesty above confidentiality
- •Lesson: interactions between policies can create unexpected emergent behavior
How the spec evolves: open internal process, new capabilities, and incident-driven updates
They outline the ongoing governance: OpenAI employees can propose updates, and changes are driven by product evolution, new model capabilities, and lessons from deployment. Examples include adding multimodal guidance, autonomy/agent principles, under-18 considerations, and updates after incidents like sycophancy.
- •Open internal collaboration: visible drafts and broad participation
- •Updates driven by new product features and capability shifts (multimodal, agents)
- •Iterative deployment informs spec revisions based on real-world learnings
- •Specific learnings (e.g., sycophancy) feed back into policy changes
- •Spec is treated as a living “North Star,” not a static rulebook
When behavior diverges: evals, retraining, and deciding whether the spec or model is wrong
Jason explains that models are non-deterministic and won’t be perfectly aligned at all times. When outputs disagree with the spec, the team decides whether the behavior is actually preferable (update the spec) or undesirable (adjust training), supported by “model spec evals” tracking compliance over time.
- •Spec often leads current model behavior—aspirational target
- •Non-determinism and training complexity make perfect compliance unrealistic
- •Mismatch triage: either revise the spec or intervene in training
- •Model Spec evals measure compliance across the document’s principles
- •Trend: models improving over time on spec alignment metrics
Smaller and reasoning models: deliberation, generalization, and chain-of-thought for alignment research
They discuss how smaller variants can still follow the spec reasonably well, especially when they’re “thinking” models trained with deliberative alignment. Jason argues chain-of-thought is crucial in alignment research (e.g., detecting strategic deception), and notes OpenAI’s emphasis on not heavily supervising chain-of-thought to preserve honesty in reasoning traces.
- •Smaller models can be well-aligned; reasoning capability helps follow policies
- •Thinking models often comply better due to explicit policy understanding
- •Chain-of-thought helps diagnose issues like scheming/strategic deception
- •OpenAI aims to avoid over-supervising chain-of-thought to keep it candid
- •Better policy understanding supports generalization to novel edge cases
Model Spec vs Anthropic’s constitution: different document purposes, similar behavioral outcomes
Jason compares OpenAI’s Model Spec to Anthropic’s constitutional approach, suggesting outcomes may be more similar than people assume. The main distinction is the Model Spec’s role as a public behavioral interface for humans versus a constitution-style document that may function more as an implementation artifact shaping model identity and training.
- •Behavioral conclusions often converge despite different framings
- •Model Spec: primarily for humans—expectations, transparency, accountability
- •Constitution approach: more implementation- and identity-oriented (as described here)
- •Not mutually exclusive—both styles can be valuable together
- •Model Spec still useful even for highly aligned models as an external benchmark
Long-term future, developer takeaways, and the “Human Spec” thought experiment
They explore the future role of the Model Spec even in an AGI scenario: it sets expectations, encodes product/value judgments, and supports coordination as agents become more autonomous. Jason encourages developers to create spec-like guidance (e.g., agents.md), stressing precise, truthful, actionable rules plus examples; they close by relating the spec to Asimov’s laws and wondering whether AI could draft a broader human-oriented spec.
- •Even with AGI, explicit policies help set expectations and encode non-obvious product choices
- •Autonomous agents may shift emphasis toward trust and positive-sum cooperation beyond “rules”
- •Prediction: more companies will create their own specs; models will learn to interpret them on the fly
- •Developer guidance: be accurate, avoid oversimplifying, make instructions actionable, use tricky examples
- •Asimov parallel: simple top-level goals aren’t enough—conflict resolution is the hard part
