The release process

The checklist

Every capability benchmark has to clear before a version ships to any real user. So does every one of the seven safety categories described elsewhere on this site. So does a specific, named sign-off from the team that owns tool-use safety on the product-level safeguards described on the Sandboxing and Connector safeguards pages. This isn't a soft goal that gets waved through when the schedule is tight. It's structured as an actual gate. Each item on it is either passed or not passed. A version doesn't move forward with an item marked as pending, or assumed to be fine without being checked.

A regression on any of the seven safety categories blocks release outright. That's true regardless of how strong the capability gains are elsewhere in that version. There's no informal exception for "but the coding benchmarks improved so much this time." A regression on a capability benchmark, by contrast, is treated as a judgment call. It's weighed against what the release fixes elsewhere, and against how large and how well-understood the regression actually is. It's disclosed in that version's own documentation, rather than quietly dropped from public discussion when it happens to be inconvenient to mention. The asymmetry there is deliberate. A safety regression is an absolute gate; a capability regression is a disclosed trade-off.

Who decides

The checklist is owned jointly by two groups. One is the team that actually built the model in question. The other is a separate safety review function that had no hand in building it. That split is structural, not a matter of internal courtesy or informal deference between teams. The specific reason is straightforward once stated plainly. The group deciding whether a release is safe enough to ship should not be the same group under schedule pressure to ship it. Those two positions create a genuine conflict of interest, even among people acting in good faith. A team that has spent months building a model naturally wants to see it ship, which is a completely human, understandable instinct, and exactly the one a separate review function exists to check.

This split doesn't eliminate schedule pressure from the process entirely. It would be misleading to claim it does. What it changes is who's positioned to say no when saying no is the correct call. That authority goes to a group whose position isn't compromised by wanting the specific release in front of them to succeed on a specific timeline. A concrete example of this working as intended is described on the tAI 4.2 page. An early development checkpoint for that version was rejected by this process. That happened despite the checkpoint being further along in the release timeline than the checkpoint that eventually shipped. That's the kind of outcome this structural split is specifically meant to make possible.

Staged rollout

A new major version isn't switched on for every user at once, even the moment it clears the checklist above. It's rolled out first to a smaller share of production traffic. The production abuse monitoring described on the Monitoring page is reviewed on a noticeably tighter cadence than normal during that initial window. Only then is it expanded in further stages, as no category shows a production-only failure mode that pre-release evaluation happened to miss. Every user on a given version, from the very first stage of that rollout onward, is running the exact same checkpoint that cleared the full checklist described above. Staging controls how many users are on that checkpoint at a given moment in time. It never, under any circumstance, controls which checkpoint a given user happens to be on.

A staged rollout is paused and reverted back to the prior version at any stage of that process, if production monitoring surfaces a safety regression that pre-release testing didn't catch. That mechanism exists for a specific, honest reason. Pre-release evaluation, however thorough the checklist above makes it sound, is still evaluation against a fixed set of conditions. It isn't a guarantee about every possible real-world condition a much larger population of live users will eventually produce. That's the same honest limit described in more depth on the Red-teaming page, applied here to the release process as a whole rather than to adversarial testing specifically. Staged rollout is the concrete mechanism that limit translates into in practice.

Point releases, not just major versions

A confirmed safety finding doesn't have to wait for the next full retraining run before it gets addressed. That's true whether the finding comes from red-teaming, production monitoring, or an external report through responsible disclosure. A targeted safety-tuning point release can address a specific confirmed finding on its own. It ships independently of the broader capability roadmap. It's tracked explicitly in that model's revision history, so the change is visible rather than silently folded into the next major version months later. Full retraining, by contrast, is reserved specifically for a finding that reflects a genuine gap in the training data or process itself. That's something a targeted tuning pass on top of an existing checkpoint structurally can't fix on its own. It's a meaningfully rarer and more involved category of response.

Documentation is part of the checklist too

A version's own security writeup, the system card and the per-model page in this section, isn't drafted after the fact once every other checklist item has already cleared. It's built in parallel with the evaluation work it describes, and it has to accurately reflect the shipped checkpoint's actual results before that version goes out. A document assembled weeks later from memory and old notes would be more prone to small inaccuracies than one written directly from the evaluation data as it's produced. Treating documentation as a genuine checklist item, not an afterthought, is how we try to avoid that. A version's writeup missing or materially incomplete at ship time is treated as seriously as a missing capability benchmark would be. That standard applies to this entire section, not only to the system card itself.

If drafting the writeup surfaces an inconsistency, a number that doesn't match what evaluation actually found, or a claim that doesn't hold up once someone has to state it plainly for a public document, that goes back to the safety review function described above. It doesn't get quietly smoothed over in the document to make the numbers look cleaner. Writing something down for a real audience has a way of surfacing exactly this kind of discrepancy, since a vague internal understanding is harder to sustain once it has to become a specific, checkable sentence someone outside the team will actually read. That's a genuinely useful side effect of holding documentation to the same standard as any other checklist item. It catches loose reasoning that a purely internal review might have let slide. More than one imprecise internal claim has been caught and corrected exactly this way, during the process of trying to write it down clearly enough for this section.