Child safety

Zero-tolerance, not a score

Every other category described on this page is reported as a rate. There's a percentage caught, a percentage missed on a fixed evaluation set, a trend that moves up or down across successive versions. Child safety is treated differently from all of them, on purpose. That difference is not a matter of degree. It's a difference in kind. Any confirmed failure in this category blocks release outright until it's resolved. That's true regardless of the roadmap, regardless of the release timeline the rest of the team is working against, and regardless of how strong every other part of that version's results happen to be. There is no acceptable rate here other than zero known, unresolved failures at the moment a version ships.

We're explicit about this distinction for a reason. It would be easy, and slightly misleading, to present this category using the same percentage-and-trend format used everywhere else on this page. Doing so would understate how differently it's actually handled internally. A 99.5% catch rate sounds impressive when it's describing cybersecurity misuse discrimination, where the remaining fraction is a real but bounded and continuously improving cost. The same framing applied here would be actively misleading. The standard this category is held to isn't "as close to 100% as reasonably achievable." It's "zero, full stop, with a release blocked until it's actually zero again." We'd rather state that plainly than let a reader infer a percentage framing that doesn't apply.

How it's evaluated

This category is checked as part of the same internal red-teaming process described in full on the Red-teaming page. It runs with a dedicated pass specific to this area, though, rather than being folded into general content-safety testing. As with hazardous-material misuse, the specific test material used here isn't published in detail. That's consistent with how this category is handled across the field generally. It isn't a policy unique to how we've chosen to run things internally. The people who build and review this specific test material have relevant background in child safety work, not just general safety-tuning experience.

The reasoning for that restraint mirrors the hazardous-material page closely. Detailed disclosure here would trade off against handing useful information to exactly the kind of person this safeguard exists to stop. That trade-off isn't one we're willing to make for the sake of transparency on this particular page. What we will say plainly is that the evaluation for this category runs before every release, with no exceptions. It uses material specifically built to probe the hardest, most ambiguous edge cases, not only the obvious ones. It's reviewed by people with the specific expertise this area requires, rather than treated as a generic extension of broader content-safety work.

What we will say

tAI's pre-release evaluation in this category has surfaced no unresolved failures at ship time for any released version to date. We mean that as a factual statement about our evaluation history, not a promise about the future we can't actually make. If that ever changes, if a future version's pre-release evaluation surfaces a real failure in this category, the honest answer is simple and non-negotiable. The release that would have shipped with an unresolved failure here doesn't ship until it's fixed. Full stop. It doesn't ship on schedule with a caveat attached to a changelog somewhere.

If you encounter something in the live product that looks like a failure in this category, report it immediately. That applies whether you're a researcher, a parent, a platform trust-and-safety professional, or just a user who noticed something wrong. Use Responsible disclosure rather than waiting to see if it happens again. Don't assume someone else has already flagged it. This is the one category across this entire section where we would genuinely rather receive ten false alarms than miss one real issue. No report in this category is ever treated as too minor or too uncertain to look into immediately.

Reporting pathways beyond this page

A report in this category is routed differently once it reaches us than a report in any of the other six. Instead of the normal triage queue described on the Incident response page, it goes to immediate, direct escalation, ahead of whatever else the safety review function happens to be working on at that moment. This category also connects to account-level enforcement beyond what's described on the Monitoring page, and, where legally required, to reporting obligations to the relevant external authorities. We're deliberately not detailing the specifics of that external reporting process on a public page. The relevant point for a reader here is that a confirmed finding in this category doesn't stop at an internal fix. It can extend to consequences well beyond a training update or a product change.

None of that changes the reporting bar itself. It's still the same low bar described everywhere else in this section: report anything you're unsure about, rather than deciding on your own it's probably nothing. What changes is what happens after the report reaches us, which in this category is faster and treated with more urgency than in any other. That's true whether the report comes from a parent, a researcher, a platform trust-and-safety professional, or an ordinary user who noticed something wrong. The channel and the urgency are the same regardless of who's reporting. We'd rather make that consistent and predictable than have it depend on who happens to be asking.