Comparison · 6 questions · 7 frameworks

Compare frameworks

What does each developer’s safety framework say on the same questions, edition by edition?

Each row is one question, worded so that it fits every framework. Each column is one framework, showing its latest edition unless you choose another. A cell gives what that edition says on the question, in its own words and with the page, or records that no passage was found in a stated search. The questions are Selekoa’s. An edition’s own terms, such as “ASL” or “Critical Capability Level”, appear only in its quotations and in the notes.

A status records what an edition states. It does not show implementation, compliance or effectiveness, and a shared row does not make two provisions equivalent.

A machine selected and arranged these records. No human review of the selection or framing is recorded.

What the statuses mean

Stated: A passage meets the question’s criterion as worded, however conditional or narrow its scope. The condition or scope is in the note.
Stated, partly: A passage has what the criterion asks for, but in a weaker form than the criterion’s own words: for example, no named person or body where the question asks for one, or a “may” where it asks for a statement that something will happen.
Recorded, not re-checked: A passage recorded earlier from an archive copy. The edition could not be retrieved again to re-check it for this comparison.
Not found in the recorded search: No passage meeting the criterion was found. The record lists the sections read, the search terms and every passage set aside, with the reason. It does not show that the developer lacks the practice, or that a provision was deleted.
Not checked: The edition could not be retrieved, and no passage on this question was recorded earlier.

Limits of this comparison

Conditions that matter are in each cell’s note. A “stated” cell can carry conditions as important as those of a “stated, partly” one.
The page compares and does not rank. There are no scores or totals, and columns are in a fixed order.
Six questions are shown, on required actions, who decides and exceptions. Eleven further questions (risk domains, thresholds, evaluation timing, reporting and revision) were prepared but are not shown, because quoting them would exceed Selekoa’s quotation limit for most editions.
Passages were selected, checked and placed under each question by machine, and checked by a reviewer from a different model family. The maintainer decided the borderline cases. No editor has reviewed the records.

Editions shown: the latest of each framework

Edition shown for each frameworkAnthropic · Responsible Scaling PolicyGoogle DeepMind · Frontier Safety FrameworkMeta · Frontier AI / Advanced AI Scaling FrameworkMicrosoft · Frontier Governance FrameworkOpenAI · Frontier Governance FrameworkOpenAI · Preparedness FrameworkxAI · Frontier AI Framework

Question	Anthropic · Responsible Scaling Policyv3.4 · effective 2026-07-08Edition text: Responsible Scaling Policy — v3.4 Archived copy, captured 2026-07-10: Responsible Scaling Policy — v3.4	Google DeepMind · Frontier Safety Frameworkv3.1 · published 2026-04-17Edition text: Frontier Safety Framework — v3.1 Archived copy, captured 2026-04-23: Frontier Safety Framework — v3.1	Meta · Frontier AI / Advanced AI Scaling Frameworkv2.0 · published 2026-04-08Edition text: Advanced AI Scaling Framework — Version 2 Archived copy, captured 2026-04-08: Advanced AI Scaling Framework — Version 2	Microsoft · Frontier Governance FrameworkFeb 2026 · revised 2026-02Edition text: Frontier Governance Framework — February 2026 Archived copy, captured 2026-04-24: Frontier Governance Framework — February 2026	OpenAI · Frontier Governance FrameworkMay 2026 edition · published 2026-05-28Edition text: Frontier Governance Framework — May 2026 edition Archived copy, captured 2026-05-29: Frontier Governance Framework — May 2026 edition	OpenAI · Preparedness FrameworkVersion 2 · published 2025-04-15Edition text: Preparedness Framework — Version 2 Archived copy, captured 2025-04-15: Preparedness Framework — Version 2	xAI · Frontier AI FrameworkJune 2026 edition · effective 2026-06-30Edition text: Frontier Artificial Intelligence Framework — June 2026 edition Archived copy, captured 2026-07-16: Frontier Artificial Intelligence Framework — June 2026 edition
Required actions when a threshold is reached
Safeguards requiredSafeguards, mitigations or standards the edition requires (or states it will apply) for a model at or above a threshold.	Stated “We will maintain or improve on our ASL-3 protections, which include classifier guards at least as robust as our initial Constitutional Classifiers” PDF p. 6, §1, threshold table, row 'Non-novel chemical/biological weapons production', middle column ('Mitigations—our plan as a company') Note: Company plans (middle column) are separated from industry-wide recommendations (right column), which the edition says it cannot unilaterally and unconditionally commit to. For the novel chemical/biological row the company column extends protections at least as strong as ASL-3 to more use cases; for the misaligned AI systems in high-stakes settings and Automated R&D rows it lists Risk Report disclosure, security and alignment projects rather than a named standard.	Stated “The following mitigation process for external deployments will be applied to models reaching a misuse T/CCL” PDF p. 10 (printed p. 10), §2.1.2 Deployment Mitigations, first sentence “We recommend a security level for each CCL” PDF p. 11 (printed p. 11), §2.2 Misuse Capability Levels, first paragraph, third sentence Note: Recommended security levels: 'Security level 2+' (defined on PDF p. 9 as RAND SL2 plus insider-threat and non-state-actor measures) for CBRN, cyber and harmful manipulation CCLs; 3 and 4 for ML R&D CCLs. A parallel deployment process applies to ML R&D and Misalignment T/CCLs (§3.1.2). For the Stealth and Situational Awareness TCL, safeguards such as chain-of-thought monitoring are applied if residual risk from internal deployment is deemed unacceptable (PDF p. 14).	Stated “Proceed with deployment of the Frontier AI only if sufficient mitigations are defined, implemented and validated to reduce risk to that of a moderate or lower model.” PDF p. 15 (printed p. 15), §3.3 Risk Thresholds, Table 1, High row, Measures column, under the label 'Deploy with mitigations' Note: Table 1 also assigns security measures: heightened access controls to model weights for High and Critical (for Critical 'as overseen by the Chief AI Officer and/or Director of Alignment and Risk … insofar as is technically feasible and commercially practicable').	Stated “Models posing high-risk on one or more tracked high-risk capability will be subject to security measures protective against most cybercrime groups and insider threats.” PDF p. 8 (printed p. 7), §4 Mitigations, Security measures, fourth paragraph, first sentence Note: Safety mitigations are applied 'so that the model’s risk level remains at low or medium once mitigations have been applied' (PDF p. 8); critical-risk models are subject to 'the highest level of security safeguards' (PDF p. 8).	Stated “OpenAI tailors these measures to the capability of a model and its deployment, as appropriate, to mitigate systemic risks to acceptable levels.” PDF p. 13 (printed p. 11), §2.5 Safety mitigations, first paragraph, second sentence Note: No tier-by-tier safeguard requirements are stated; safeguards are tied to residual risk being within acceptable levels. Security mitigations are listed in §3 (PDF pp. 16–17).	Stated “Covered systems that cross this capability threshold are required to have robust and effective safeguards … before they are deployed and appropriate security controls as they are developed.” PDF p. 5 (printed p. 4), §2.2 Tracked Categories, first paragraph, sentence following the definition of High capability thresholds Note: Refers to High thresholds. Table 1 lists risk-specific safeguard guidelines, and Appendix C gives illustrative safeguards and the security practices required for High capability models (PDF pp. 17–22).	Stated, partly “xAI implements appropriate safety mitigations to address the systemic risks stemming from our models” PDF p. 6, second §2.3 'Safety mitigations', first sentence (opening) “xAI will maintain a documented Security Goal that identifies the threat actors against which mitigations are designed to protect against, including sophisticated non-state actors, insider threats, state-sponsored actors and other foreseeable actors.” PDF p. 7 (no printed page numbers), §2.4 Security mitigations, first paragraph, first sentence Note: Mitigations are not keyed to named thresholds; the closest threshold-linked provision is the risk-acceptance condition quoted under “Pause, non-deployment or non-training”. CBRN-specific heightened safeguards are triggered by prompts demonstrating intent (PDF p. 3).
Pause, non-deployment or non-trainingA statement that development, training or deployment will stop, pause or not proceed when required safeguards are not in place or a level is reached.	Stated “We will require a strong argument that catastrophic risk is contained, along the lines of our recommendations for industry-wide safety (see Section 1). We will delay AI development and deployment as needed to achieve this, until and unless we no longer believe we have a significant lead.” PDF p. 17 (printed p. 17), Appendix A: Commitments Related to Competitors, table row 'Anthropic in the lead', Commitment column “the commitments below do not preclude us from taking cautionary action, such as refraining from training or deploying models, in other circumstances.” PDF p. 17 (printed p. 17), Appendix A: Commitments Related to Competitors, introductory paragraph, second-to-last sentence Note: Delay commitments are tied to Appendix A competitor scenarios (see “Provisions conditioned on other developers”); outside them the edition says it would 'strongly consider' pausing (conditional wording, added in v3.1). No passage commits to not training or deploying a model without adequate safeguards (the dataset records that provision as not found in this edition).	Stated “Pre-deployment review of residual risk assessment: external deployments of a model take place only after the appropriate governance function determines the residual risk to be acceptable (including a safety case where a CCL has been reached).” PDF p. 10 (printed p. 10), §2.1.2 Deployment Mitigations, numbered step 2, first sentence Note: A deployment gate: external deployment (and, under §3.1.2, high-risk internal deployment) takes place only after a governance determination that residual risk is acceptable. The misuse deployment-mitigation acceptance criterion is 'required only for external deployment, not internal deployment or further development' (PDF p. 7). No passage states that development will be put on hold.	Stated “Should either scenario arise, we will only continue development of the Frontier AI if our risk assessments are complete and safeguards are defined, implemented and validated to reduce risk to the moderate or lower risk threshold.” PDF p. 17 (printed p. 17), §3.3 Risk Thresholds, final sentence of the paragraph beginning on PDF p. 16 ('First, a Frontier AI meets the critical risk threshold…') Note: Applies to either critical-threshold scenario. Development and deployment are conditioned on validated mitigations rather than stopped; for cyber, a model meeting the simple-suite threshold is provisionally rated high and 'such deployment will not be implemented' until complex evaluation is complete (PDF p. 29); the change log records the critical measure changing from 'Stop' to 'Develop with Mitigations' (see “Stated changes from the previous edition”).	Stated “If, during the implementation of this framework, we identify a risk we cannot sufficiently mitigate, we will pause development and deployment until the point at which mitigation practices evolve to meet the risk.” PDF p. 9 (printed p. 8), §4 Mitigations, Safety mitigations, paragraph 'Post-mitigation capability assessment and safety buffer', second sentence Note: The pause is tied to unmitigable risk rather than to reaching a level; high or critical models are 'subject to further review and safety and security mitigations prior to deployment' (PDF p. 7).	Stated “If residual risks associated with the model exceed acceptable risk levels, the model is not deployed unless additional mitigation measures are implemented that sufficiently minimize risk.” PDF p. 13 (printed p. 11), §2.5 Safety mitigations, first paragraph, third sentence Note: The condition is residual risk relative to acceptable levels, not a named tier; the statement concerns deployment, not training.	Stated “We do not deploy models that reach a High capability threshold until the associated risks that they pose are sufficiently minimized.” PDF p. 4 (printed p. 3), §1 Introduction, third bullet ('Safeguard against severe harms'), second sentence “If a model under development reaches a Critical capability threshold, we also require safeguards to sufficiently minimize the associated risks during development, irrespective of deployment plans.” PDF p. 4 (printed p. 3), §1 Introduction, third bullet Note: The deployment statement is conditioned on risks being 'sufficiently minimized'. §4.3 allows adjustment of required safeguards under stated conditions (see the competitor facet).	Stated “xAI will only proceed with the development, the making available on the market, and/or the use of the model, if the systemic risks stemming from the model are determined to be acceptable.” PDF p. 6, first §2.3 'Systemic risk acceptance determination', fourth paragraph, first sentence
Who decides
Determination of capability or safeguard adequacyThe person, office or body the edition names as making or approving the determination that a threshold is reached, that safeguards are adequate, or that a model may be deployed.	Stated “CEO and RSO will make the ultimate determination regarding the adequacy of the risk assessment and any downstream deployment or development plans.” PDF p. 13, §3.4 Procedures, item 3 ('Executive approval'), second sentence Note: The determination is tied to approval of a Risk Report rather than to a per-threshold capability or safeguards determination. The RSO's duties also include approving relevant model development or deployment decisions (§4, item 1).	Stated “Pre-deployment review of residual risk assessment: external deployments of a model take place only after the appropriate governance function determines the residual risk to be acceptable (including a safety case where a CCL has been reached).” PDF p. 10 (printed p. 10), §2.1.2 Deployment Mitigations, numbered step 2, first sentence Note: The 'appropriate governance function' is not named. The same function may also exempt low-risk external deployments from a critical capability assessment (see “Other exceptions or discretion”).	Stated “Based on this pre-mitigation risk assessment, the Chief AI Officer and Director of Alignment and Risk2 will assign a risk threshold.” PDF p. 6 (printed p. 6), §2.1.2 Evaluate and Mitigate, 'Evaluate for performance and safety', paragraph beginning 'These assessments typically use a version of the Frontier AI', second sentence “Informed by this analysis, the Chief AI Officer or the Director of Alignment and Risk will determine whether to request further testing or information, require additional mitigations or improvements, or approve the model for deployment.” PDF p. 7 (printed p. 7), §2.1.3 Decide, 'Make a decision on deployment', second sentence Note: Threshold assignment names both officers ('and'); the deployment decision names either ('or'). §2.3 adds that deployment follows 'with the approval of the Chief AI Officer' (PDF p. 10).	Stated “The Executive Officers (or their delegates) will make the final decision on whether to approve the recommendation for secure and trustworthy deployment.” PDF p. 10 (printed p. 9), §5 Governance, Risk-informed deployment decision, second paragraph, first sentence Note: No named role assigns the pre-mitigation score; the Executive Officers are those 'responsible for Microsoft’s AI governance program'.	Stated, partly “We document a justification for why the systemic risks stemming from the model are acceptable, including reasonably foreseeable conditions under which the justification may no longer hold, as informed by recommendations from OpenAI’s Safety Advisory Group and external experts, as available and appropriate.” PDF p. 13 (printed p. 11), §2.5 Safety mitigations, second paragraph, second sentence “Additional detail about our deployment governance can be found in Appendix B of the PF.” PDF p. 20 (printed p. 18), §6 Allocation of responsibility for risk management, final sentence Note: The edition does not itself name who makes the acceptance or deployment determination; it names advisers and refers to the Preparedness Framework's Appendix B.	Stated “OpenAI Leadership can approve or reject these recommendations, and our Board’s Safety and Security Committee provides oversight of these decisions.” PDF p. 4 (printed p. 3), §1 Introduction, final paragraph, second sentence Note: The SAG reviews the Capabilities Report and decides on next steps (§3.3, PDF p. 10) and assesses whether safeguards sufficiently minimize risk (§4.2, PDF p. 11); Appendix B gives OpenAI Leadership (the CEO or a designee) all final decisions, including deployment go/no-go (PDF p. 16).	Not found in the recorded search
Board or external oversightA role the edition gives to a board, board committee, trust, or external party in overseeing or reviewing those decisions.	Stated “In the event that marginal risk analysis (see previous section) plays a major role in a decision to move forward, explicit approval of the Risk Report by the Board and LTBT (rather than just the CEO and RSO) will be required.” PDF p. 14 (printed p. 14), §3.4 Procedures, item 5 ('Modified process when marginal risk analysis is important to our case') “In addition, upon the LTBT’s request, we will conduct a public or private external review of our Risk Report or sections thereof, subject to the procedures outlined below.” PDF p. 14 (printed p. 14), §3.6 External Review, final paragraph before §3.6.1 Note: Otherwise the CEO and RSO share their decision(s), the Risk Report and internal feedback with the Board and LTBT after approval (§3.4 item 4). External reviewers of Risk Reports are selected with the Board consulted and LTBT approval required (from v3.2) and asked to publish commentary (§3.6); an approximately annual third-party review of procedural compliance is commissioned (§4).	Not found in the recorded search Note: Internal reviews with escalation are described (§4.1, PDF p. 16); the facet asks for a board, trust or external party.	Stated, partly “Meta’s Board of Directors provides oversight of the company’s product and regulatory compliance” PDF p. 10 (printed p. 10), §2.3 Accountability, third paragraph, final sentence Note: The board role is stated as general product and regulatory compliance oversight, not a specific role in framework decisions. An internal governance function periodically reviews risk management practices (same paragraph).	Stated, partly “This framework is subject to Microsoft’s broader corporate governance procedures, including independent internal audit and board oversight.” PDF p. 10 (printed p. 9), §5 Governance, 'Oversight and reporting channels', first sentence Note: The board role is stated through general corporate governance; no specific board review of framework decisions is described.	Stated “The board of directors of OpenAI Ireland Limited exercise systemic risk oversight under this Framework for EU purposes.” PDF p. 20 (printed p. 18), §6 Allocation of responsibility for risk management, final paragraph Note: Material updates to the Framework go to the OpenAI Foundation board's Safety and Security Committee and the OpenAI Ireland Limited board for oversight (§7.1, PDF p. 21).	Stated “OpenAI Leadership can approve or reject these recommendations, and our Board’s Safety and Security Committee provides oversight of these decisions.” PDF p. 4 (printed p. 3), §1 Introduction, final paragraph, second sentence “Where necessary, the Board may reverse a decision and/or mandate a revised course of action.” PDF p. 16 (printed p. 15), Appendix B 'Decision-making practices', paragraph on the Safety and Security Committee, final sentence	Not found in the recorded search
Exceptions and discretion
Provisions conditioned on other developersA provision that relaxes, adjusts or conditions the developer’s safeguards or commitments on what other developers do or have (often called a “race” or “marginal risk” clause). Scope tests that decide whether a model is covered by the framework are recorded as context, not counted.	Stated “we will meet or exceed the overall risk reduction posture of these competitors” PDF p. 17, Appendix A, table row 'Competitors have strong safety measures', Commitment column, first sentence “We will make a significant effort to meet or exceed that performance standard. However, we will not necessarily delay AI development and deployment in this scenario.” PDF p. 17, Appendix A, table row 'General upleveling', Commitment column, second sentence Note: Appendix A ('Commitments Related to Competitors') has three scenarios; the 'Anthropic in the lead' delay is recorded under “Pause, non-deployment or non-training”. §1 says Anthropic cannot unilaterally and unconditionally commit to the industry-wide recommendations, framing the change as a collective action problem. Where a decision relies on marginal risk analysis, Risk Reports add a competitive landscape analysis (§3.3) and need Board and LTBT approval (§3.4).	Stated “if other models are similarly capable and have few mitigations, then the marginal risk added by our external deployment is likely low” PDF p. 7 (printed p. 7), §1.3.5 Risk Acceptance Determination, misuse T/CCL bullet, first sub-bullet, parenthetical example “a model does not possess capabilities meaningfully different from other publicly available models that have weaker security applied” PDF p. 11 (printed p. 11), §2.2 Misuse Capability Levels, second paragraph, second sentence	Not found in the recorded search Note: Comparative scope and reference-class provisions, not a waiver of safeguards conditional on other developers. Appendix I compares a model with 'the most advanced models' (not limited to Meta's) to decide whether it is Frontier AI (PDF p. 41); §2.1.1 compares a planned model 'against our own models and those available externally' to identify a 'reference class' used to anticipate risks and required assessments (PDF p. 4). Both are recorded here as context.	Stated, partly “considers the marginal capability uplift … including currently available open-weights models.” PDF p. 7 (printed p. 6), §3, Deeper capability assessment, 'Holistic risk assessment' bullet, final sentence Note: A marginal-uplift consideration in the risk determination, measured against available tools and open-weights models; it does not state that measures change depending on other developers’ actions.	Not found in the recorded search Note: Exemption from Model Report updates by reference to the EU Code of Practice's similarly-safe-or-safer test, whose safe reference model may be another provider's model (Code, Appendix 2.1); governs reporting only, not safeguards.	Stated “another frontier AI model developer might develop or release a system with High or Critical capability … without instituting comparable safeguards” PDF p. 13 (printed p. 12), §4.3 Marginal risk, first paragraph, first sentence “If we are able to rigorously confirm that such a scenario has occurred, then we could adjust accordingly the level of safeguards that we require in that capability area, but only if:” PDF p. 13 (printed p. 12), §4.3 Marginal risk, first paragraph	Not found in the recorded search
Other exceptions or discretionAny other stated exception, deviation, override or room for judgement in applying the framework.	Stated “not hard commitments but rather public goals” PDF p. 3, Introduction, paragraph on Frontier Safety Roadmaps, final sentence “making judgment calls on policy interpretation and application” PDF p. 16, §4 Governance, item 1 ('Responsible Scaling Officer'), duty (6) Note: Further room for judgement: Appendix A says Anthropic will often have to use its best judgment on whether a competitor scenario applies; Risk Reports may record deviations from described mitigations (§3.2); redactions may be made for listed reasons 'not limited to' those (§3.5); a report is 'significantly redacted' in the judgment of the RSO, CEO, Board or LTBT (§3.6).	Stated “A critical capability assessment may not be conducted for low-risk external deployments (e.g. to a small number of trusted testers)” PDF p. 5 (printed p. 5), §1.3.2 Inherent Risk Assessment, footnote 4 Note: §1.3.3 (PDF p. 6) says the specific mitigations implemented 'may be determined when a T/CCL is reached'. Security adequacy may also be assessed on other grounds than the recommended level (§1.3.5), and the closing Note says assessments 'will often involve some level of subjective analysis' (PDF p. 8).	Stated “Final deployment decisions may also consider additional factors beyond those covered in this Framework.” PDF p. 15 (printed p. 15), §3.3 Risk Thresholds, Table 1, note below the Measures column, second sentence Note: Other stated room for judgement: cyber capabilities may be made available 'to qualified and trusted customers where appropriate' (PDF p. 30); chemical and biological capabilities may be offered to trusted researchers 'with reduced mitigations via structured access controls' (PDF p. 33, research area), and non-material modifications are presumed to inherit the underlying model's threshold (PDF p. 17).	Stated “the marginal benefits of a model outweigh any residual risk” PDF p. 10 (printed p. 9), §5 Governance, Risk-informed deployment decision, first paragraph, numbered point 2) Note: Point 2 is one element of the recommendation submitted for the deployment decision.	Stated “also reflects a holistic judgment based on the totality of available evidence” PDF p. 8 (printed p. 06), §2.3 Systemic risk acceptance determination, final paragraph, final sentence “We will not consider an update necessary if (1) the model’s capabilities have not materially changed since the last update” PDF p. 18 (printed p. 16), §4 Model reporting › 'Model report updates', final sentence	Stated “OpenAI Leadership can also make decisions without the SAG’s participation” PDF p. 16 (printed p. 15), Appendix B, SAG responsibilities, fifth bullet Note: Other stated room for judgement: threshold determinations reflect 'holistic judgment' (PDF p. 10); footnote 6 states that distilled, fine-tuned or quantized models from a model below High will ordinarily not require additional safety measures (PDF p. 10); disclosures may be redacted or summarized (PDF p. 14).	Stated “The final decision also reflects an overall judgment based on all the available evidence” PDF p. 6, first §2.3 'Systemic risk acceptance determination', third paragraph, third sentence “xAI may change its approach from that listed above in order to make additional improvements.” PDF p. 7, second §2.3 'Safety mitigations', paragraph following the safeguards list, second sentence Note: The December 2025 trusted-user and benefits-outweigh-benchmark clauses do not appear in this edition.