Frontier training under a safety case

You must now be able to substantiate any decision to proceed with frontier training using documented evidence from evaluations, containment tests and live monitoring, with recorded assumptions, residual risk and a defined pause mechanism. Proceeding becomes an auditable decision, not a statement of intent.

An analysis of 29 September 2026 of frontier training safety cases argues that the shift from general safety principles toward demonstrable, evidence-backed arguments is the most consequential change for anyone governing frontier training. The concrete case is a structured dossier that substantiates continuation of a training run before it proceeds, linking safety claims to supporting evidence from alignment evaluations, containment tests and live monitoring. In our assessment, this development means that risk management for frontier training now requires you to maintain versioned, auditable documentation of claims and evidence per run, with mechanisms for continuous update as conditions change and incidents emerge.

What distinguishes a safety claim from a safety case?

A safety claim is a single assertion about safety. A safety case is the broader substantiated argument that wraps claims in evidence, documented assumptions, uncertainty and residual risk. The distinction matters because it moves the burden from stating intent to demonstrating it. The case is drawn up before a potentially capability-increasing run proceeds, and it connects three technical pillars—alignment training, containment and monitoring—with concrete measures and evidence such as evaluations, backtesting, stress tests, immutable transcripts, live monitoring and rapid response.

Treating the safety case as a versioned document with traceable provenance per claim means you can reconstruct which assumption held at which moment after an incident. That alignment with how model behaviour changes over time—drift is structural, not exceptional—makes the case a maintained, auditable artefact rather than a static document.

Which failure modes and risk categories does the framework address?

• Misalignment during training — model behaviour diverges from intended objectives during the run itself, not only at deployment.
• Containment failure — safety measures designed to limit model capability or scope prove ineffective under live conditions.
• Undetected capability emergence — the model develops capabilities not captured by pre-run evaluations or benchmark scores.
• Assumption drift — conditions or dependencies documented before the run no longer hold as training progresses.
• Incident blindness — serious incidents occur but are not detected, logged or investigated systematically.
• Veto capture — pause or stop authority exists formally but is overruled in practice, rendering it a suggestion rather than a control.

What concrete controls must you be able to demonstrate?

1. Record the safety claims and their evidence — document which claims apply to the run, what evidence supports each claim, and the source of that evidence (evaluations, tests, monitoring data).
2. Establish immutable transcripts and live monitoring — capture agent actions, model outputs and system behaviour in real time in a form that cannot be altered after the fact, and review logs systematically during and after the run.
3. Define and document assumptions and residual risk — state explicitly what conditions or dependencies the safety case assumes to hold, and what risks remain even if all claims are substantiated.
4. Appoint independent scrutiny with genuine pause authority — designate a reviewer or assessor with the power to halt the run, and ensure that authority is operational and cannot be overruled by the training team.
5. Version and update the case as conditions change — treat the safety case as a living document; refresh evaluations, update assumptions and add new evidence as the run progresses and incidents emerge.
6. Investigate serious misalignment incidents independently — when the model behaves in ways that contradict safety claims, conduct a systematic investigation and update the case accordingly.

Why do benchmark scores alone not substantiate a decision to proceed?

Benchmark scores capture model performance on defined tasks before the run begins. They do not capture what emerges during live operation—novel capability combinations, unexpected failure modes, or behaviour that contradicts pre-run assumptions. Real-time monitoring during agent operation and systematic review of agent logs are practical controls for assessing whether safety commitments work in practice. Relying only on benchmark scores or pre-run documentation leaves out evidence that surfaces during operation and through subsequent log review or incident investigation.

What are the limits of this framework?

The proposal is explicitly aspirational and in development, not a binding standard. A safety case lowers risk through substantiation and scrutiny, but does not guarantee safety or rule out failure. More importantly, the sources leave a critical question open: how are the proposed independent assessments and pause controls made operational and enforced in practice? Anyone who formally appoints a reviewer or pause authority but can overrule it in practice has no veto but a suggestion.

Tooling can help you maintain versioned documentation, log immutable transcripts and flag anomalies in live monitoring. What remains your own professional judgement is whether the evidence substantiates the claims, whether the assumptions are sound, and whether the residual risk is acceptable. The framework is a structure for that judgement, not a substitute for it.