Did GPT-5.5 “Spud” have a safety evaluation? Public evidence is still missing

Verdict: insufficient public evidence

There is evidence that OpenAI, as a company, uses safety and alignment processes. OpenAI describes iterative deployment, learning from real-world use and post-deployment monitoring as parts of its safety approach. It also describes external and automated red teaming, and its Red Teaming Network is framed as a community of trusted, experienced experts who help inform risk assessment and mitigation.

That supports a limited claim: OpenAI has general safety and red-team practices. It does not prove a stronger claim: GPT-5.5 “Spud” has a published, model-specific safety evaluation. To prove that, the evidence would need to name Spud directly, or OpenAI would need to say that Spud is covered by a specific, already published safety document.

What would count as strong evidence?

For readers who do not live inside AI release paperwork: a “system card” is typically a model-release document explaining a model’s evaluated capabilities, risks, mitigations and known limitations. “Red teaming” means adversarial testing — trying to make a model fail in risky or policy-violating ways before or after deployment.

Strong evidence for a Spud safety review would usually include:

• An official OpenAI system card, or a direct GPT-5.5 “Spud” entry on OpenAI’s Deployment Safety Hub, which is where OpenAI posts system cards and related updates.
• A deployment-safety, Preparedness or risk-assessment document that directly names GPT-5.5 “Spud”.
• A credible external red-team report that names the exact model version, then explains methods, scope, failures and limitations.
• An OpenAI announcement explicitly saying that GPT-5.5 “Spud” is covered by a specific GPT-5-series safety document.

By contrast, YouTube explainers, Reddit or Facebook discussion, prediction-market questions and leak-style blog posts can be useful leads — but they are not, by themselves, proof that a public safety evaluation exists.

What the public record does show

OpenAI’s safety and alignment page says the company uses iterative deployment to understand threats from real-world use, and that models are supported by measures such as continuous monitoring after deployment.

OpenAI has also published material on external red teaming. One important caveat in that material is that red teamers may sometimes test pre-deployment models or snapshots, but those snapshots — especially before post-training — generally do not represent the final production safety profile.

That distinction matters. Even if there are rumors about early tests, internal code names or pre-deployment snapshots, those rumors do not establish the safety profile of a final released model unless the tested model version, deployment state and evaluation scope are clearly identified.

GPT-5 has safety documents. That is not the same as Spud having them

The GPT-5 record is clearer. OpenAI’s GPT-5 System Card says GPT-5 models include safe-completions, a safety-training approach designed to prevent disallowed content. OpenAI’s Deployment Safety Hub also lists GPT-5-related evaluation and deployment-safety material, including references to gpt-5-thinking and gpt-5-main.

The arXiv version of the GPT-5 System Card says Microsoft AI Red Team concluded that gpt-5-thinking showed one of the strongest AI safety profiles among OpenAI’s models.

But these documents are explicitly about GPT-5, gpt-5-thinking, gpt-5-main or other listed GPT-5 models. In the reviewed sources, they do not directly name GPT-5.5 “Spud”, and OpenAI is not shown mapping Spud to those documents.

So the GPT-5 system card is real evidence about GPT-5. It should not be treated as direct evidence about Spud unless OpenAI makes that connection.

The Spud trail is mostly rumor, not audit evidence

The sources reviewed mention Spud mainly in non-official or secondary contexts: YouTube videos, Reddit and Facebook posts, Manifold prediction-market discussion, and blog or news-style articles discussing release windows, pretraining, live testing, capability speculation or claims of final safety review.

Some pages even frame Spud as released or as entering final safety review. But without public methods, model-version details, risk classifications, red-team results or an official safety conclusion, those claims are not a checkable Spud-specific safety artifact.

GPT-5 and gpt-oss testing cannot be copied over to Spud

Some sources do discuss safety testing of OpenAI models — just not GPT-5.5 “Spud”. Promptfoo and SPLX discuss GPT-5 red-teaming or security testing. Kaggle’s OpenAI gpt-oss-20b Red-Teaming Challenge, and related commentary, focus on gpt-oss-20b and gpt-oss safety evaluation.

Those materials help explain how AI red teaming can be conducted. They do not prove that Spud itself had a public pre-release safety evaluation.

Evidence table

What would change the conclusion?

The verdict should be updated if any of the following appears:

1. An official OpenAI GPT-5.5 “Spud” System Card.
2. A new OpenAI Deployment Safety Hub entry directly naming GPT-5.5 “Spud”.
3. A deployment-safety, Preparedness or risk-assessment document that names Spud and describes scope, risk categories and limitations.
4. A credible external red-team report that names the model version, test methods, scope, failures and limitations.
5. An OpenAI announcement explicitly stating that Spud is covered by a particular GPT-5-series safety document.

Until then, the most accurate phrasing is: OpenAI has public general safety, alignment and red-teaming processes, and GPT-5 has official safety documentation. But the reviewed public sources do not prove that GPT-5.5 “Spud” had a directly corresponding public safety evaluation, red-team report or alignment assessment before announcement.

That does not prove OpenAI did no internal testing. It means unpublished internal work cannot be cited as public evidence.