Alignment

Model specification. Maintain and publish a model specification: a document with the rules, guidelines, and guardrails for intended model behavior.¹The model specification need not be the literal document used for training. The document should describe intended behavior of the system, after safeguards.

Safety-critical coverage. Ensure the specification addresses:

Specification governance. Keep the specification under version control with a public changelog for material changes.⁷The published version may be less detailed than internal materials, but it must be comprehensive: no intended model behavior should be surprising in light of it. Publicly designate the version that governs each deployed model.

Specification stress-testing. Stress-test the specification for underspecified, contradictory, or ambiguous provisions before material changes take effect and before a new most-capable modelmost-capable modelThe model or AI system designated by the developer as showing the best performance on complex tasks, compared with the developer's other models under similar conditions. Should be designated per threat category. is trained to it; revise it and record the findings in the changelog.

Specification-consistent training. Design the signals that shape model behavior⁹e.g., supervised fine-tuning demonstrations produced under the specification, reward models that incorporate compliance with it, and programmatic or verifiable rewards. to be consistent with the specification, so that performing well does not require violating it. Where consistency cannot be guaranteed, demarcate the data as such, so that its effect on deployment behavior can be measured.¹⁰Signals that typically cannot be guaranteed consistent with the specification include pretraining data and RL environments where cheating cannot be ruled out. Demarcating data (e.g., with control sequences) enables measurement of how much of the behavior learned there carries over into deployment. Some techniques also use the demarcation to discourage that carry-over; inoculation prompting is one. Whether those techniques work is still under study; this practice does not require them.

Training across the range of use. Train the model to behave as specified across the foreseeable range of use,¹¹Revisit coverage when deployment expands materially (cf. 3b). including:

Training objective audits. Audit training objectives and environments for specification violations before and during their use.¹⁷Audits include reviewing samples of fine-tuning data, checking RL environments for reward hacks and other specification violations, checking data for poisoning, and checking for training signals that act on monitored channels (further addressed in 4a–4b). Ensure each training environment satisfies a maintained set of requirements, and red-team both the audits and the training-time monitors.¹⁸The coverage may include disclosing the fraction of data or environments checked. Environment requirements include, e.g., that graders cannot access the model's reasoning traces. Red-teaming means compromising some data or environment, or injecting misbehavior, and verifying that it is detected and escalated to a directly responsible individual with authority to pause training. The monitors are those of 2d, not the deployment monitors of the Control Standard. Document the methods and coverage of each audit.

Training-time behavior checks. Robustly monitor the model during training for misaligned behavior,¹⁹Specification violations, reward hacking, and other misaligned behavior. Robust monitoring implies using multiple distinct methods, including automated review of logged episodes and sampled human review of reasoning traces and rollouts; maintaining predefined classes of concerning behavior (e.g., attempted bypass of safeguards, gaming of monitors, sandbox escape, coordination with other AI instances through unsanctioned channels) each with a prespecified response (e.g., pause of the rollout or environment, halt of the run); every automated detection path escalating to the directly responsible individual (who may pause the implicated environments or data, or the run and who may approve restarting); and retaining logs of training episodes and tool calls, linked to the checkpoint and environment, for root-cause investigation (5b). and escalate detections to a directly responsible individual with authority to pause training until the cause is addressed.

Misbehavior evaluation suite. Maintain and run held-out evaluations²³Held-out evaluations are kept out of training and out of iteration on training. Where possible, use evaluations maintained by external evaluators, up to fully held-out evaluations whose contents the developer never sees. for concerning misbehavior,²⁴Covering, at minimum, the categories of concerning behavior enumerated in the Control Standard (practice 2b), including deception and dishonesty, reward hacking and specification gaming, sandbagging and capability concealment, susceptibility to instruction-hierarchy subversion (e.g., via prompt injections), sabotage of safety-relevant work, self-preservation and avoidance of shutdown, inappropriate autonomous action, and misbehavior in oversight roles (e.g., motivated mislabeling as a judge, grader, or monitor). Check for regressions in alignment-relevant propensities and for over-optimization of learned rewards. derived from documented threat models of misalignment,²⁵cf. the threat modeling practices of the Capability Testing Standard (Principle 1). on training checkpoints and on candidates for deployment. Maintain a list of coverage gaps relative to the threat models.

Realistic evaluations. Create and run evaluations that approximate deployment,²⁶With realistic configurations (e.g., scaffolds, tools, memory, sub-agents) including significantly new deployment configurations such as a new flagship system prompt. Production traffic includes internal pilot traffic. including honeypot scenarios, samples of production traffic, and scenarios reconstructed from misbehavior caught by control measures.²⁷Reproducing, as evaluations, misbehavior that deployment monitoring has actually caught.

Open-ended auditing. Search, through automated auditing and red-teaming, for misbehavior that the evaluation suite does not anticipate,²⁸e.g., by automated auditing agents that probe the model across many scenarios, and human red-teaming. and document the methods used.

Evaluation validity. Establish whether the evaluation process would detect a dangerously misaligned model:

Evaluation process red-teaming. Publish in advance how the developer will respond if the evaluation process fails to detect a model organismmodel organismA model with known misalignment, whether deliberately implanted or naturally arising, that is useful for scientific study and safety testing.’s misalignment.³⁶e.g., reviewing the assessment's validity and adopting stronger evidence requirements under 3d-iv. Results are reported in the alignment assessment (6a). Regularly red-team the evaluation process with model organismsmodel organismA model with known misalignment, whether deliberately implanted or naturally arising, that is useful for scientific study and safety testing.,³⁷Including organisms produced by training processes resembling the developer's own. and record the results, including failures to detect.

Pre-deployment gate. Publish in advance which results on the evaluations covering the most severe forms of misalignment would trigger which responses.³⁸e.g., heightened control measures or preclusion of use. Results and triggered responses are included in the next alignment assessment (6a). Do not deploy a risk-relevant modelrisk-relevant modelsModels that could materially contribute to catastrophic risk. This includes any model deployed internally that meets or exceeds the threshold for frontier models articulated by California SB 53 (10^26 FLOPs of training compute)., internally or externally, until a pre-designated decision-maker has reviewed its results on those evaluations against the published triggers.

Monitorability impact assessment. Before adopting⁴⁰Adoption means use in training a risk-relevant model. Small-scale experiments are not adoption, but the measurement must precede scaling up. a training method or architecture that could degrade monitorability,⁴¹The ability to detect misalignment through reasoning traces or other monitored channels. Methods and architectures of concern include optimization pressure on reasoning traces or on internal model features, and architectures that materially increase the computation performed between human-legible outputs (e.g., latent or recurrent reasoning). The measurement should include the model's capability to perform relevant tasks without legible reasoning. Measured impacts and compensating measures are reported in the alignment assessment (6a). measure the impact, weigh it in the adoption decision, and plan compensating measures.

Reasoning-trace integrity. Do not optimize reasoning traces to look benign, or penalize them for revealing misbehavior.⁴²As distinct from penalizing the misbehavior itself. Penalizing "bad thoughts" has been observed to produce misbehavior that evades chain-of-thought monitors rather than eliminating it. Methods that supervise reasoning content for alignment purposes (e.g., deliberative alignment) involve unresolved tradeoffs (see "Alignment reasoning data" under this principle's directions).

No training against detection signals. Do not use the monitors, audits, and held-out evaluations that detect misalignment as training signals.⁴³Including to filter training data. Document which signals are used for training and which for detection, and any exceptions.

Escalation channelsescalation channelA sanctioned affordance by which a model can flag a task as broken, impossible, or in conflict with the specification, or report observed misalignment in other AI systems, to the developer’s oversight processes.. Give models a sanctioned way, in training, evaluation, and deployment, to (i) flag broken, impossible, or specification-conflicting tasks and (ii) report observed misalignment in other AI systems.⁴⁴Without a sanctioned alternative, training on broken or impossible tasks rewards models for hacking the task or misreporting success. An escalation channel removes that incentive and produces an oversight-relevant and specification-consistent signal. Do not penalize legitimate use of these channels.

Preservation for investigation. Retain tamper-evident⁴⁵Tamper-evident as in the Control Standard (1d): deletion or modification is detectable. For training episodes and tool calls this involves append-only, integrity-protected, timestamped records that are retained outside of the training environment's write authority. These records should be linked to the exact model checkpoint, environment, and weights, and retained for the published period. intermediate checkpoints, training data provenance, and training and deployment logs for a defined and published period.

Severity criteriaseverity criteriaThe criteria published under practice 5a for which misaligned behaviors and incidents are severe enough to trigger root-cause investigation (5b), inclusion in the misalignment report (6b), and independent investigation (7c).. Publish severity criteriaseverity criteriaThe criteria published under practice 5a for which misaligned behaviors and incidents are severe enough to trigger root-cause investigation (5b), inclusion in the misalignment report (6b), and independent investigation (7c). determining which misaligned behaviors and incidents require root-cause investigation (5b), inclusion in the misalignment report (6b), and independent investigation (7c).⁴⁶For incidents, the criteria may be those of the developer's incident definition under the Transparency Standard (practice 2a); the criteria here also cover misaligned behavior found in training and evaluation that never results in an incident.

Root-cause investigation. Before or alongside mitigation, conduct a root-cause analysis of the five most severe instances of misaligned behavior found since the previous alignment assessmentalignment assessmentThe document required by practice 6a that contains conclusions about a model’s misalignment risk, the methodology and evidence behind them, and the supporting results. and of any behavior meeting the severity criteriaseverity criteriaThe criteria published under practice 5a for which misaligned behaviors and incidents are severe enough to trigger root-cause investigation (5b), inclusion in the misalignment report (6b), and independent investigation (7c)..⁴⁷Five is a floor; the developer’s severity criteria capture severe cases beyond it. Identify the causes in training, the oversight measures that failed, and the model’s own reasoning and motivation.⁴⁸Causes in training include the contributions of reward signals, training data, the specification, and elicitation, and whether the behavior was isolated, repeated, or reinforced by training. Oversight measures include environment design, graders, and monitors. The model's process is characterized at minimum from its reasoning traces, and with attribution or interpretability methods where available. Update the evaluation suite where it did not anticipate the behavior and document the findings for the misalignment report.⁴⁹The report required in practice 6b.

Generalization of fixes. When correcting misaligned behavior, measure and document whether the fix generalizes.⁵⁰Whether the fix holds in held-out variations of the eliciting contexts; when the behavior is elicited at least as strongly as it originally was (for behavior surfaced in deployment, by deliberately reproducing and strengthening the conditions that elicited it); in contexts the model does not recognize as evaluations, where possible; and for other behaviors the root-cause analysis implies should improve.

Alignment assessmentalignment assessmentThe document required by practice 6a that contains conclusions about a model’s misalignment risk, the methodology and evidence behind them, and the supporting results.. Before internal deploymentinternal deploymentAny usage of the model beyond training, evaluations by the safety/evaluations team(s), or safety testing by trusted third parties. Some examples that would constitute internal deployment include “dogfooding” (or use by employees in their work), and especially use in automated AI research, to generate training data, critiquing other models, or in agentic pipelines for research. of a new most-capable modelmost-capable modelThe model or AI system designated by the developer as showing the best performance on complex tasks, compared with the developer's other models under similar conditions. Should be designated per threat category.,⁵¹A material change to the deployed configuration of a most-capable model (a change to how a deployed model is run that is significant enough that prior alignment conclusions may not carry over, e.g., a new flagship system prompt, new levels of autonomy, categorically distinct tools) warrants an update to its assessment. synthesize the results of the practices above into an alignment assessmentalignment assessmentThe document required by practice 6a that contains conclusions about a model’s misalignment risk, the methodology and evidence behind them, and the supporting results. and provide it to third parties.⁵²Those with access under practice 7a. Publish it before external deployment, or within three months of internal deploymentinternal deploymentAny usage of the model beyond training, evaluations by the safety/evaluations team(s), or safety testing by trusted third parties. Some examples that would constitute internal deployment include “dogfooding” (or use by employees in their work), and especially use in automated AI research, to generate training data, critiquing other models, or in agentic pipelines for research. if the model is not externally deployed.⁵³The assessment states the conclusions about misalignment risk and the evidence and assumptions they rely on, the methodology and its limitations, the basis for believing the assessment would have detected misalignment were it present, and the results that underlie the conclusions. Where material is redacted from the publication, provide it to third parties and state the extent to which the redactions affect the stated conclusions. Include the results from: training across the range of use (2b), training objective audits (2c), training-time behavior findings (2d), the evaluation suite's coverage gaps (3a), realistic evaluation and open-ended auditing results and methods (3b, 3c), evaluation limits, documentation, evaluation awareness measurements, tests beyond the training distribution, and registered predictions (3d), evaluation process red-teaming outcomes (3e), pre-deployment gate reviews (3f), monitorability impacts (4a), signals used for training and for detection, and exceptions (4c), escalation channel design (4d), generalization of fixes (5c), the third-party access provided (7a), and the conditions under which the developer will re-assess the model and renew third-party access.

Misalignment report. Publish quarterly a misalignment report containing the findings of Principle 5 for behaviors meeting the developer’s severity criteriaseverity criteriaThe criteria published under practice 5a for which misaligned behaviors and incidents are severe enough to trigger root-cause investigation (5b), inclusion in the misalignment report (6b), and independent investigation (7c)., the comparison of registered predictions with observations (3d-vi), and any decision not to deploy a model, or to delay or restrict its deployment, because of misalignment findings.⁵⁴Containing the comparison of registered predictions with observations (3d-vi), root-cause analyses and resulting fixes (5b), and advances in alignment methods. For deployment decisions driven by misalignment findings, include the findings themselves, so that near-misses are visible outside the developer. The report may be published as a section of the quarterly risk report described in the Transparency Standard (Principle 1). Report misalignment incidents within the time window required by the Transparency Standard (practice 2e).

Training process transparency. Publish, for each most-capable modelmost-capable modelThe model or AI system designated by the developer as showing the best performance on complex tasks, compared with the developer's other models under similar conditions. Should be designated per threat category., an overview of the training pipeline covering:⁵⁵The overview may be published in the alignment assessment or the model's system card.

Alignment approach transparency. Publish the developer's planned approach for aligning successively more capable systems,⁶⁰The capability regimes in which its current techniques are expected to remain effective and why; its intended approach for regimes where they are not; and the status of its work toward that approach. and update it when its assumptions are observed to be failing.

Third-party model access. Before internal deploymentinternal deploymentAny usage of the model beyond training, evaluations by the safety/evaluations team(s), or safety testing by trusted third parties. Some examples that would constitute internal deployment include “dogfooding” (or use by employees in their work), and especially use in automated AI research, to generate training data, critiquing other models, or in agentic pipelines for research. of a new most-capable modelmost-capable modelThe model or AI system designated by the developer as showing the best performance on complex tasks, compared with the developer's other models under similar conditions. Should be designated per threat category., give third parties sufficient access and time to independently test it for misalignment and review the developer’s conclusions. Disclose the access provided in the alignment assessmentalignment assessmentThe document required by practice 6a that contains conclusions about a model’s misalignment risk, the methodology and evidence behind them, and the supporting results..⁶¹Including the lead time before each deployment, the evaluators' independence and funding arrangements, and the terms governing publication of findings, which should permit publication after editing for responsible disclosure, free of legal or technical retaliation. Confidentiality arrangements may apply to items iii–vi. For the reports under 7b, access includes organizational access such as interviews with relevant staff. Access must include, at minimum:

Third-party adequacy reports. On a quarterly basis, obtain and publish an independent third-party report that:

Independent incident investigation. For incidents that meet the developer’s severity criteriaseverity criteriaThe criteria published under practice 5a for which misaligned behaviors and incidents are severe enough to trigger root-cause investigation (5b), inclusion in the misalignment report (6b), and independent investigation (7c)., give qualified external investigators requisite access to investigate root causes,⁶⁵Including logs, environments, and affected checkpoints (4e). and publish their conclusions subject only to safety-relevant redactions.