Audience: AI safety teams, frontier model governance leads, policymakers assessing voluntary safety commitments, and auditors evaluating preparedness evidence. Also relevant for organizations deploying OpenAI models that need downstream governance documentation.
Critical Assessor Notice: SWT3 is an independent witness protocol. It does not inspect, filter, modify, or improve any AI system. It records what happened and produces tamper-evident evidence. This guide maps framework commitments to witness procedures -- it does not claim that SWT3 makes any system safer, more prepared, or compliant. The organization deploying the model is responsible for its own preparedness practices. SWT3 provides the evidence layer.
1. Preparedness Framework Overview
The Preparedness Framework defines four risk categories for frontier model evaluation:
- Cybersecurity: Ability to assist with cyberattacks, vulnerability discovery, or exploit development.
- CBRN (Chemical, Biological, Radiological, Nuclear): Ability to provide uplift for weapons of mass destruction.
- Persuasion: Ability to generate targeted, personalized persuasion at scale.
- Model Autonomy: Ability to act autonomously in ways that are difficult to monitor or correct.
Each category uses a 4-level risk scorecard: Low, Medium, High, Critical. Deployment thresholds require that models scoring "High" in any category receive enhanced safeguards, and models scoring "Critical" must not be deployed.
The evidence gap: The scorecard is an internal assessment. When a regulator or auditor asks "what risk level was this model assessed at before deployment?", the answer is a document -- not a verifiable attestation. SWT3 anchors the assessment itself, producing tamper-evident evidence that the evaluation occurred, what the outcome was, and when the deployment decision followed.
2. Risk Category Crosswalk
| Risk Category | Assessment Type | SWT3 Procedure | Evidence Produced |
|---|---|---|---|
| Cybersecurity evaluation | Capability assessment | AI-ASSESS.1, AI-REDTEAM.1 | Red team + capability eval attestation |
| Cybersecurity monitoring | Post-deploy monitoring | AI-CYBER.1 | Cybersecurity risk attestation |
| CBRN evaluation | Capability assessment | AI-ASSESS.1, AI-REDTEAM.1 | Structured eval with CBRN scope |
| CBRN monitoring | Post-deploy monitoring | AI-DRIFT.1 | Drift detection for capability regression |
| Persuasion evaluation | Capability assessment | AI-ASSESS.1, AI-FAIR.1 | Bias and persuasion metric evaluation |
| Persuasion monitoring | Output monitoring | AI-DRIFT.1, AI-GRD.1 | Guardrail + drift evidence |
| Model autonomy evaluation | Capability assessment | AI-ASSESS.1 | Autonomy benchmark evaluation |
| Model autonomy monitoring | Runtime monitoring | AI-HITL.1, AI-SAFE.1 | Human oversight + safe state evidence |
Coverage key: Each mapping identifies the SWT3 procedure that records verifiable evidence for the corresponding risk category activity. The witness protocol records that the activity occurred -- it does not perform the evaluation itself.
3. Scorecard and Threshold Evidence
Champion-Challenger Assessment
The primary procedure for recording risk scorecard evaluations. Each risk category receives its own assessment anchor, producing four independent witness records per model release.
Factor encoding: fa = assessment metric identifier, fb = threshold value (numeric score or level mapping), fc = pass/fail flag. An organization produces 4 anchors (one per risk category) per model version evaluated.
The deterministic fingerprint formula ensures that any anchor can be independently recomputed and verified without trusting the original minting system. This is critical for voluntary frameworks where the evaluating organization and the deploying organization may be different entities.
AI-ASSESS.1 anchors filtered by model version. Confirm that all four risk categories were evaluated before any deployment anchor was minted. Missing categories represent an evidence gap.
Safe State Transition
Records the deployment decision that follows assessment. Links back to assessment anchors via cycle_id, creating a verifiable chain from evaluation to deployment authorization.
A deployment anchor (AI-SAFE.1) without 4 preceding assessment anchors (one per risk category) is a finding. The absence of evidence is itself evidence -- an auditor can query the ledger for the expected sequence and identify gaps.
AI-SAFE.1 anchors and cross-reference with AI-ASSESS.1 anchors sharing the same cycle_id. Any deployment preceded by an assessment with a critical-level factor value warrants investigation.
4. Post-Deployment Monitoring Evidence
Pre-deployment evaluation is necessary but insufficient. The Preparedness Framework requires ongoing monitoring for capability changes, and SWT3 provides the evidence layer that proves monitoring is active and continuous.
Drift Detection
Records continuous monitoring for capability changes post-deployment. The framework requires ongoing evaluation -- a single pre-deployment assessment is insufficient. Regular AI-DRIFT.1 anchors prove that monitoring is active and provide a timestamp trail showing monitoring frequency.
For CBRN and persuasion categories, drift detection is especially important: a model that scored "Medium" at deployment could shift toward "High" through fine-tuning, data contamination, or emergent behavior. Continuous witness records document that this risk was monitored.
AI-DRIFT.1 anchors. Long gaps between anchors indicate periods without active monitoring. Compare drift factor values over time to identify capability trajectory.
Performance Metrics
Records model performance baselines and deviations. Relevant for detecting capability regression or unexpected improvement -- which could indicate fine-tuning that bypasses the evaluation pipeline. A model that gains new capabilities after deployment without a new round of AI-ASSESS.1 anchors represents an evidence gap.
AI-PERF.1 factor values against the original AI-ASSESS.1 baseline. Significant deviations without corresponding reassessment anchors indicate the evaluation cadence may be insufficient.
Incident Lifecycle
When monitoring detects an issue, the incident lifecycle chain records the full response sequence: detection, triage, investigation, and resolution. Each phase produces its own anchor linked by cycle_id, creating a verifiable timeline that auditors can reconstruct.
cycle_id and confirm all phases are present. An incident with a detection anchor but no investigation or resolution anchor indicates an incomplete response.
5. Incident Response Evidence
The Preparedness Framework implies that critical-severity findings require immediate response, including the ability to suspend deployment. SWT3 provides the evidence chain that documents the full incident lifecycle.
Emergency Override Lifecycle
For critical-severity findings, the emergency override lifecycle captures the full response: trigger condition, authorization, model suspension, investigation, and resolution or permanent retirement. Each phase is a separate anchor in a linked chain, producing a forensic trail that survives even if the model runtime is terminated.
This procedure is especially relevant for the "Critical" scorecard level, where the framework states that deployment must not proceed. An AI-EMRG.1 chain documents that the organization took action when a critical finding was identified post-deployment.
Human Oversight
Records that human review occurred during incident investigation. Override rates and response times provide evidence of meaningful -- not rubber-stamp -- oversight. The Preparedness Framework's governance structure involves a Safety Advisory Group and the Board of Directors for high-severity decisions. AI-HITL.1 anchors document that human judgment was exercised at the appropriate level.
AI-HITL.1 anchors during the investigation phase indicates automated-only response. The Preparedness Framework implies human oversight is required for High and Critical findings. Check the agent_id field to confirm the reviewer identity.
6. Clearing Levels for Risk Assessments
Risk assessment data is highly sensitive. Capability evaluation details for frontier models could themselves be dangerous if disclosed inappropriately -- a tension the Preparedness Framework acknowledges between transparency and information hazard. SWT3 clearing levels resolve this by allowing different evidence fidelity for different audiences from the same witness event.
| Level | Data Fidelity | Audience | Use Case |
|---|---|---|---|
| L0 -- Analytics | Full assessment data including capability measurements | Internal safety teams | Detailed evaluation review |
| L1 -- Standard | Assessment outcomes with risk scores | Compliance and legal teams | Regulatory preparation |
| L2 -- Sensitive | Pass/fail per category with hashed metrics | Board reporting, regulatory submission | Governance oversight |
| L3 -- Classified | Binary deployment authorization evidence only | Public transparency reports | External accountability |
The framework's tension: Transparency demands that the public know whether a model was evaluated and deemed safe for deployment. Information security demands that specific capability measurements (especially for CBRN and cybersecurity) not be disclosed broadly. Clearing levels allow a single witness event to produce evidence at all four fidelity levels simultaneously, with each audience receiving the appropriate detail without compromising the others.
AI-DRIFT.1 and AI-GRD.1 anchors, creates a layered evidence chain that satisfies both upstream and downstream governance requirements.
7. References
- OpenAI Preparedness Framework (December 2023, updated 2025)
- SWT3 Protocol Specification and SDK Documentation
- UCT Registry -- Unified Control Taxonomy