Delaying Internal Deployments Until After X Days of Safety Testing

* A minimum, fixed testing period is required before a new model can be deployed internally.
* This waiting period can be adjusted regarding duration (calendar time or conditions) and what it blocks (external deployment, internal deployment, or training).
* One concrete implementation target is that no checkpoint may be used internally beyond safety testing until $X$ calendar days after its hash is filed with an auditor.
* Continuing to train a checkpoint's own weights does not count as internal use.
* The waiting period can block the training of future checkpoints, which was rejected due to incentivizing fewer checkpoints for testing and algorithmic overhang.
* A model family becomes covered when any checkpoint is substantially more capable than the last model that completed its wait.
* An emergency clause allows an auditor to authorize early use of a named checkpoint for specific incidents.
* The waiting period introduces time delays for safety testing, potentially allowing misalignment behaviors to be caught through subsequent monitored internal use.
* Potential mitigation strategies include staged testing and parallel, hidden runs for testing during the waiting period.

The core tension in this proposal lies in pacing accelerated AI development against the need for safety verification and risk mitigation. The proposal attempts to introduce a friction point—a mandatory delay ($X$ days) tied to external audit—to force reflective evaluation before internal deployment, contrasting with existing pacing methods like compute caps. The critical implications center on defining the scope of "safety testing" versus permissible AI Research and Development (R&D). If safety research is done with a model that is $X$ days behind, it risks creating an imbalance where safety investigations are conducted with less up-to-date capability, yet this delay might impede the flow of necessary misalignment signals.
The mechanisms proposed for gaming the system—such as running parallel, hidden runs or using specialized R&D tasks disguised as testing—highlight a systemic vulnerability: the rule relies heavily on transparency and the developer's adherence to the defined scope of "safety testing." The potential for developers to mask acceleratory R&D under the guise of safety testing suggests that policy must move beyond simple temporal barriers and establish verifiable boundaries around knowledge generation.
The question of how $X$ increases, and how capability is measured ("substantially more capable"), points to a recursive dynamic where pacing itself becomes an evolving metric reflecting the speed of self-improvement. If external deployment delays cause only second-order effects on revenue or race dynamics rather than stopping progress entirely, the primary impact shifts to modulating the pace of recursive self-improvement (RSI). The effectiveness hinges on creating robust, independent audit mechanisms capable of judging dynamic capability evolution without impeding necessary research signals.
Bridge Questions: How can auditing protocols be designed to rigorously distinguish between genuine safety testing and performative capability assessment? What structure is necessary to ensure that safety research conducted with delayed models still provides maximally useful signals for alignment researchers? If the framework is used as a speed dial, what safeguards prevent this mechanism from being weaponized against legitimate internal R&D loops?