OpenAI's Updated Model Spec: Turning Behavioral Values Into Company Controls

On October 29, 2026, OpenAI published an updated Model Spec organized around five values meant to guide more capable AI. Three are named: sound judgment, human agency, and faithfulness to human intent ¹. For any company deploying AI, the real work starts after the announcement. Broad values have to become requirements a team can test, review, and act on when a system falls short.

Treat the OpenAI Model Spec as a Control-Design Input, Not a Policy Statement

OpenAI frames the update as guidance for more capable AI, organized around five core values ¹. That makes it relevant to anyone deciding what AI behavior is acceptable in products or internal workflows, not just to the people building the models.

A value is a direction for behavior. A control is a way to check whether a specific behavior met the organization's bar. The gap between the two matters the moment a model response influences a customer decision, triggers an action, or feeds work a person later signs off on.

Treating values as policy text alone leaves that gap open. A team still has to define what the model should do in a specific workflow, what counts as failure, who reviews the uncertain cases, and what evidence is required before release. The Model Spec gives a reference point. The company still has to do the operational work. If your team routes models through an enterprise AI gateway, that is also the layer where some of these controls, such as allowed models and providers, can be enforced. For a related look at governance as the real buying decision, see OpenAI and ServiceNow Announce an Enterprise AI Integration; Governance Remains the Decision.

What the Source Confirms: Three Named Values, Two Undefined

The available excerpt names three of the five values (sound judgment, human agency, and faithfulness to human intent) and states there are five in total ¹. It does not identify the other two or explain how any of the five are defined or measured in practice ¹.

The excerpt also does not mention evaluation methods, review processes, escalation rules, or evidence that models follow these values in deployment ¹. Naming a principle is not the same as telling a deployment team how to assess behavior or decide whether a model is ready for a given use.

Companies should not treat this list as a finished AI governance framework. Use it as policy input, then write the company's own interpretation for each workflow. Before claiming an internal control register covers all five values, confirm the full set against the source, since the available excerpt leaves two unconfirmed.

Turning a Value Into a Testable Requirement

Start by writing the behavior expected in one specific workflow. Don't stop at restating the value. Each requirement needs:

• Expected behavior: what the system should do
• Failure condition: what response or action is unacceptable
• Test: the input or scenario that checks it
• Review owner: who decides pass or fail
• Evidence: the record another reviewer can inspect later
• Escalation: what happens when the result is ambiguous or fails

These are proposed company controls, not procedures the Model Spec prescribes in the available excerpt. They're what makes a principle reviewable. A team might define a requirement that an assistant ask for clarification rather than pick between two conflicting user instructions. The test checks that behavior directly; the evidence includes the input, the response, the reviewer's decision, and any exception granted.

Keep each requirement linked back to its value in the control register. That link lets policy owners explain why the requirement exists, while the pass/fail criteria give product and safety reviewers something concrete to check. For the two unnamed values, mark them pending confirmation rather than guessing at names or meanings.

Defining AI Human Agency for a Specific Workflow

Human agency is one of the three named values ¹. For a company, the starting point is defining where a person must keep a meaningful choice, approval, or ability to correct an AI-assisted outcome.

The control should match the workflow. A system that drafts content needs a different review point than one that recommends a decision or initiates an action on its own. Specify what the model may do without a person and exactly when it must pause.

Test beyond whether a review button exists in the interface. Use scenarios with ambiguous instructions, conflicting preferences, and requests that appear to exceed the user's stated authority. These are proposed evaluation cases, not examples from the source. Record whether the system preserved the user's ability to decide, and whether a reviewer agreed with that call. Ambiguity is a rich source of failures; Tool-Using Agents Need Tests for Users Who Leave Things Unsaid covers one angle on building such tests.

A board-level review should ask whether the workflow preserves control where it matters, not whether human review is technically available somewhere in the flow. If a system acts before a person can understand or reverse the outcome, that review point isn't doing its job.

Sound Judgment and Faithfulness Are Different Failure Modes

Sound judgment and faithfulness to human intent are both named values ¹. Don't collapse them into one generic helpfulness score. A system can understand an objective perfectly and still handle its consequences badly. It can also make a cautious, careful decision while completely misreading what the user wanted.

A faithfulness check tests whether the system carried out an authorized objective without quietly adding one of its own. A judgment check tests whether it recognized uncertainty, conflicting instructions, or a situation calling for refusal or escalation. These are proposed interpretations for control design; the available excerpt doesn't define the values in these terms.

When a test fails, classify why. Did the system misread the goal? Follow the request too literally? Miss a cue that the situation called for a different response entirely? Separating these causes helps teams pick the right fix instead of filing every failure under model quality. The same distinction shows up in A Correct SQL Query Can Still Answer the Wrong Question.

Where ownership splits along these lines, assign separate owners for product intent and safety judgment, and document how disagreements get resolved and who can block a release. This is an implementation recommendation, not a process the Model Spec specifies.

Evidence for AI Behavior Evaluations: Test Records, Not a Policy Statement

A policy document is not proof of behavior. Evidence has to connect a requirement to evaluation results, reviewed examples, and documented exceptions.

Build representative test sets per workflow: routine cases, ambiguous instructions, adversarial inputs, and situations that should trigger escalation. These are recommended categories for company evaluations, not tests OpenAI reports in the source. Record whether each case passed, why, and whether a human reviewer agreed.

Keep the records traceable: requirement, test input, model response, assessment, exception or remediation. That's what lets a reviewer examine the reasoning behind a release decision, not just a pass rate on a dashboard.

Repeat evaluations after any material change to the model, prompt, tools, or workflow. The available excerpt names values but specifies no monitoring program ¹. Ongoing evaluation is a company control, not something OpenAI mandates. And don't mistake the Model Spec itself for proof of compliance. It establishes the values. The excerpt says nothing about how any model performs against them ¹. When you compare candidate models for a workflow, a governed model catalog makes it easier to rerun the same test set against each one.

Before Production: Build the Value-to-Control Register

Start with a value-to-control register listing the five values described in the source, with the two unnamed ones flagged for confirmation ¹. For the three named values, pick a small set of high-consequence workflows and write acceptance criteria specific to each.

Assign an owner to every criterion and define the evidence required before release. Set an escalation path for failed or ambiguous cases: who can pause deployment, who decides a failure has been fixed. Run the evaluations before launch and after every material change, and keep review records that product, safety, and executive stakeholders can all read without translation.

Pick one workflow this week. Write its first testable requirements, and get product, safety, and policy owners to agree on pass criteria and the escalation route before that system touches production traffic.

FAQ

When did OpenAI publish the updated Model Spec?

OpenAI published the updated Model Spec on October 29, 2026 ¹.

How many core values does the updated Model Spec contain?

The source says it outlines five core values intended to guide more capable AI ¹.

Which Model Spec values are identified in the available source?

The source names sound judgment, human agency, and faithfulness to human intent. The available research notes do not identify the other two ¹.

Does the source specify how companies should evaluate adherence to the values?

The available research notes do not specify evaluation methods, review processes, escalation rules, or evidence showing that models follow the values in practice ¹.

How should companies use the Model Spec in AI governance?

Use its values as policy inputs, then define workflow-specific behaviors, tests, reviewers, evidence requirements, and escalation rules. That translation is an implementation recommendation based on the source, not a procedure specified in it ¹.