A FEW PLACES TO STARTEXPLORE WEBSPACEAI

Company · Company explainer

How our safety risk levels work

The published AI Safety Framework describes four risk levels. Here is how to read the escalation and release controls without confusing a policy with a test result.

On this page

THE ESSENTIALS

  • The source policy defines four levels: minimal, moderate, high, and critical risk.
  • Controls and release authority escalate with the assigned level.
  • A risk classification does not by itself prove that a system is safe.

Company explainer

What the source actually says

The AI Safety Framework currently published in the policy suite defines four levels. Level 1 is minimal risk, Level 2 moderate risk, Level 3 high risk, and Level 4 critical risk. This explainer follows that source rather than the earlier five-level wording on the homepage. [1]

The framework describes a progression of evaluation, review, access restrictions, and release controls. These are policy requirements. Assigning a level is not a substitute for the supporting assessment, and a description of a required control is not evidence that a particular product has passed it.

Company explainer

How the controls escalate

The source describes standard evaluation and product-level approval at Level 1; fuller safety evaluation and internal red teaming at Level 2; external red teaming, restricted access, and governance approval at Level 3; and a paused release pending mitigation with heightened approval requirements at Level 4. See the complete policy for its conditions and review cadence. [1]

LevelClassification in the policyIllustrative control summary
1Minimal riskStandard evaluation and product-level approval
2Moderate riskFuller evaluation and internal red teaming
3High riskExternal red teaming, restricted access and governance review
4Critical riskRelease paused pending mitigation and heightened approval

Company explainer

The evidence behind a decision matters

A meaningful release decision needs to connect the intended use of a system with its evaluated capabilities and risks. The related Safety Evaluation, Red Teaming, and Human Oversight policies describe further parts of that process. A reader should look for what was tested, under which conditions, what failed, and who is responsible for follow-up. [2, 3, 4]

An evaluation report can support a bounded conclusion. It should not be stretched into a claim that a model is safe for every environment or that all future risks have been eliminated. The same care applies when reading a concise company update.

Company explainer

A clarification, not a new evaluation result

This article clarifies the policy currently presented on the website. It does not report a completed safety assessment, assign a risk level to a new model, or announce a release approval. The full documents remain the appropriate place to inspect scope, exceptions, responsibilities, and reporting routes.

This is a policy-based company explainer, not a verified import from Threads.

A CLOSER LOOK

Ask this article.

Local evidence assistant

Ask a question to find passages and their references. Answers are extracted from this article; no live AI model is connected.

READ THE ORIGINAL WORK

Sources & references

Sources reviewed 20 October 2026. Papers describe their own models and experiments; our proposed experiments are identified separately.

  1. 1
    AI Safety Framework, document 24 ↗

    WEBSPACEAI published policy suite · Document content reviewed 20 October 2026

    WEBSPACEAI policy suite
  2. 2
    Safety Evaluation Policy ↗

    WEBSPACEAI published policy suite · Document content reviewed 20 October 2026

    WEBSPACEAI policy suite
  3. 3
    Red Teaming Policy ↗

    WEBSPACEAI published policy suite · Document content reviewed 20 October 2026

    WEBSPACEAI policy suite
  4. 4
    Human Oversight Policy ↗

    WEBSPACEAI published policy suite · Document content reviewed 20 October 2026

    WEBSPACEAI policy suite