Minimum required pacing: align it fully before training the next one

Guides 0 views

A pacing gate would require labs to resolve AI alignment issues via red teams before training or deploying newer models.

Key Takeaways

  • The proposal sets a minimum pacing gate: labs should not train the next-generation frontier AI model until all significant alignment issues in the current generation are resolved.
  • It replaces a blanket pause with structured checkpoints, where independent alignment organizations red-team models throughout training and require a robust safety case before deployment.
  • Deployment should begin narrowly with trusted users and expand only after the model survives a significant issue-free period; any major alignment failure triggers reset, root-cause analysis, and retraining.
  • The Mach 2 / Mach 3 analogy emphasizes that launching a more dangerous next-generation system before understanding current failures would be unacceptable for other risky technologies.
  • The rule remains a heuristic, leaving open questions such as how to define a model generation, handle fixes that increase capabilities, and enforce independent alignment thresholds.

Meta description: A pacing proposal for frontier AI models requires resolved alignment issues before next-generation training, framed by Mach 2 and Mach 3 jet safety analogy.
Tags: AI alignment, frontier models, safety case, red teaming, deployment gates
Featured image: Abstract checkpoint gates and deployment loops, no real people, no company logos, no text

The proposal for pacing frontier AI models moves the debate away from an outright pause. It asks what minimum standard should gate the next generation of capabilities, and answers that a lab should not train a newer, more capable model until it has adequately resolved all significant alignment issues in the present generation. The Mach 2 and Mach 3 jet analogy frames the point: one should not launch a Mach 3 jet before figuring out why a Mach 2 jet keeps crashing. For other dangerous technology, “shrug and move on” would not be acceptable.

Background: Why pace rather than pause

The premise is coordination on pace, not a blanket halt. The proposal speaks to two camps in the alignment debate. Prosaic-alignment optimists, who expect current techniques to fix present issues, might see a moderate coordinated slowdown as enough to make each generation adequately safe. Prosaic-alignment pessimists, who doubt current techniques, might expect the same pacing gate to produce an extended pause, buying time to discover new fundamental approaches to aligned AI.

Both camps can accept a minimum requirement that goes beyond simple scoreboards. A model that “scores better than previous models on our metrics” is not adequate. If a user later points out a “weird but alarming thing” that was not noticed before deployment, that is a critical failure in the process as well as in the model.

Development: Checkpoints, restricted deployment, and reset rules

The proposed standard begins with multiple independent alignment organizations examining and red-teaming the newest model at many checkpoints throughout training, with full access to the data and the best tools available. Issues must be taken seriously whether they appear in a metric or feel qualitatively off, whether the model has a bad attribute or reviewers cannot robustly conclude that it has a good one.

Early training issues may not be a showstopper, but there must be a robust safety case for why later stages of training will resolve them. A model of a new generation is ready for restricted deployment only when the alignment organizations are satisfied with it. Restricted deployment starts with a group of trusted users doing tasks that don’t contribute to model training and monitoring, while the alignment organizations watch for new issues.

If a significant alignment issue arises during restricted deployment, the process is to pull the model, do a root cause analysis of the issue and why it was not caught during training, find a principled way to fix the disease rather than the symptom, train the next model of the current generation accordingly, and start again at the top.

Broader deployment comes only after the model has survived a significant period of restricted deployment without any issues arising. Internal or external deployment then continues under the same logic: if a significant alignment issue arises during broader deployment, the lab should hit reset as outlined. Only if no alignment issues have come up over a significant stretch of deployment time may the lab begin training a next-generation model. The proposal treats this as a minimum requirement, not a fully adequate standard.

Latest: What the proposal still leaves open

The pacing rule is a heuristic, not a concrete proposal, and it invites expansion. Several obvious missing pieces remain, aside from standard implementation problems. How should “a generation of models” be defined, within one lab or across several labs? What should happen if a fix for an alignment issue also significantly increases capabilities? How would an agreement be defined and enforced if labs are unable to steer solely by predefined metrics? When is an alignment issue big enough to halt the model, especially when there is obvious pressure from the lab to set the threshold high?

The Mach 2 and Mach 3 analogy leaves one tension visible: maybe a Mach 2 jet crashes for a reason that stops being a problem at Mach 3. But it would be crazy to assume that. What matters now is how independent alignment organizations, checkpoints, safety cases, and deployment reset rules could turn this minimum standard into an enforceable pacing process.

Tags: AI alignmentfrontier modelsred teamingsafety casedeployment gates

Comments

No comments yet. Be the first to comment.

Leave a comment