Audience: AI safety researchers, frontier lab governance teams, policymakers evaluating voluntary commitments, and auditors assessing responsible scaling evidence. Also relevant for organizations building on Anthropic models that need to demonstrate downstream governance.
SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.
1. RSP Framework Overview
The Responsible Scaling Policy framework defines four AI Safety Levels based on model capabilities:
- ASL-1: Models with no meaningful uplift for catastrophic risks. Minimal safeguards required.
- ASL-2: Models that show early signs of dangerous capabilities but do not exceed current state-of-the-art. Standard safeguards apply.
- ASL-3: Models that substantially increase risk of catastrophic misuse. Enhanced safeguards, red team testing, and deployment restrictions required.
- ASL-4: Models that could pose catastrophic risks in the near term. Maximum safeguards, containment protocols, and government notification required.
Key RSP Commitments
- Capability evaluations before deployment decisions
- Defined thresholds for safety level transitions
- Containment protocols proportional to assessed risk
- Red team testing at each safety level
- Deployment pause if safeguards are not ready before a level transition
The evidence gap: RSP commitments are promises. There is no standardized evidence format for proving they were followed. An auditor asking "show me evidence of your capability evaluation" receives a PDF report or an internal memo -- not a cryptographically anchored attestation chain. A policymaker referencing RSP as a benchmark has no way to independently verify whether commitments were honored on a per-model, per-deployment basis.
SWT3 closes this gap. It does not evaluate whether RSP commitments are sufficient. It does not judge whether Anthropic's safety practices are adequate. It records that specific RSP-aligned activities occurred, when they occurred, and produces tamper-evident evidence that survives organizational turnover, model updates, and post-hoc narrative revision.
2. ASL-Level Crosswalk
| RSP Commitment | ASL Level | SWT3 Procedure | Evidence Produced |
|---|---|---|---|
| Pre-deployment capability evaluation | ASL-2+ | AI-ASSESS.1 | Champion-challenger assessment with evaluation metrics |
| Red team testing | ASL-2+ | AI-REDTEAM.1 | Red team exercise attestation with scope and findings |
| Deployment go/no-go decision | ASL-2+ | AI-SAFE.1 | Safe state transition with decision rationale |
| Model drift monitoring | ASL-2+ | AI-DRIFT.1 | Drift detection attestation per monitoring window |
| Consequence-mapped drift thresholds | ASL-3+ | AI-DRIFT.2 | Threshold configuration with action triggers |
| Emergency override protocol | ASL-3+ | AI-EMRG.1 | Emergency override lifecycle chain |
| Containment verification | ASL-3+ | AI-ROBUST.1 | Robustness evaluation attestation |
| Human oversight attestation | ASL-2+ | AI-HITL.1 | Human-in-the-loop verification with override rates |
| Incident reporting | ASL-2+ | AI-INCIDENT.1 | Incident lifecycle with severity and response |
| Performance baseline | ASL-2+ | AI-PERF.1 | Performance metric attestation |
Reading this table: The ASL Level column indicates the minimum safety level at which the RSP commitment becomes applicable. Procedures can be used at any level, but the RSP framework expects them at the indicated threshold and above.
3. Capability Evaluation Evidence
RSP requires capability evaluations before any deployment decision. The evaluation determines whether a model has crossed a safety level threshold and whether corresponding safeguards are in place. Two procedures capture this evidence chain.
Champion-Challenger Assessment
RSP alignment: Pre-deployment capability evaluation against defined thresholds.
What SWT3 witnesses: Records the evaluation of a model against defined capability thresholds. The "champion" is the current safe model; the "challenger" is the candidate under evaluation. The witness anchor attests that an evaluation occurred, captures evaluation metrics, and records the pass/fail determination. SWT3 does not perform the evaluation -- it records that one took place and what the outcome was.
Evidence factors: Factor A captures the evaluation identifier. Factor B captures the metric result. Factor C captures the threshold comparison outcome.
Red Team Exercise Attestation
RSP alignment: Structured adversarial testing at each safety level before deployment.
What SWT3 witnesses: Records that a structured red team evaluation occurred, including scope (what was tested), methodology reference, and findings summary. The witness anchor does not contain the raw findings -- it attests that testing happened, how broadly it covered the threat surface, and whether the findings met the threshold for deployment approval.
Evidence factors: Factor A captures the exercise scope identifier. Factor B captures the methodology reference. Factor C captures the findings classification.
AI-ASSESS.1 and AI-REDTEAM.1 anchors before any AI-SAFE.1 deployment decision. A deployment decision without preceding evaluation evidence is a finding.
4. Deployment Decision Evidence
RSP commits to pausing deployment if safeguards are not ready before a level transition. This requires verifiable evidence of the decision itself -- who authorized it, what evaluation preceded it, and what conditions were attached. Two procedures capture the deployment lifecycle.
Safe State Transition
RSP alignment: Deployment go/no-go decision with state transition tracking.
What SWT3 witnesses: Records the deployment decision with the previous state, the target state, and the authorization chain. The lifecycle chain links pre-deployment evaluation anchors (AI-ASSESS.1, AI-REDTEAM.1) to the deployment decision anchor, creating a verifiable sequence: evaluate, test, decide. A "no-go" decision is equally valuable evidence -- it proves the pause commitment was honored.
Evidence factors: Factor A captures the state transition identifier. Factor B captures the previous state. Factor C captures the target state and authorization.
Emergency Override
RSP alignment: Emergency model suspension when safety thresholds are breached.
What SWT3 witnesses: Records emergency model suspension as a lifecycle chain capturing the full override sequence: trigger condition, authorization, suspension confirmation, investigation status, and resolution. Each step in the chain is a separate witness anchor linked by a shared cycle_id, creating a forensic timeline of the emergency response.
Evidence factors: Factor A captures the trigger condition. Factor B captures the authorization reference. Factor C captures the action taken (suspend, investigate, resolve).
AI-EMRG.1 chain without a resolution anchor indicates an open emergency. For ASL-3+ models, open emergencies should trigger immediate review.
5. Containment and Monitoring Evidence
RSP requires containment protocols proportional to risk and continuous monitoring for capability drift. Three procedures capture the containment and monitoring evidence chain.
Drift Detection and Consequence-Mapped Thresholds
RSP alignment: Continuous monitoring for capability drift with defined response triggers.
What SWT3 witnesses: AI-DRIFT.1 records drift detection attestations per monitoring window -- evidence that monitoring is active and what it observed. AI-DRIFT.2 adds consequence-mapped thresholds: when drift exceeds a defined threshold, the anchor records both the threshold configuration and the triggered action (notification, escalation, or automatic suspension). Together, they provide continuous evidence that monitoring was not just configured but actively producing results.
Evidence factors: AI-DRIFT.1 -- Factor A captures the monitoring window. Factor B captures the drift metric. Factor C captures the observation result. AI-DRIFT.2 -- Factor A captures the threshold identifier. Factor B captures the measured value. Factor C captures the triggered action.
Robustness Evaluation
RSP alignment: Adversarial testing and containment verification proportional to safety level.
What SWT3 witnesses: Records adversarial testing and containment verification results. The anchor attests that robustness testing occurred, what attack surface was evaluated, and whether containment boundaries held. This is distinct from red teaming (AI-REDTEAM.1): robustness evaluation focuses on containment integrity, while red teaming focuses on capability misuse potential.
Evidence factors: Factor A captures the evaluation scope. Factor B captures the test methodology. Factor C captures the containment verification result.
AI-ROBUST.1 (containment tested), AI-DRIFT.1 (monitoring active), AI-DRIFT.2 (thresholds configured). Missing any link in this chain indicates incomplete containment posture.
6. Clearing Levels for Safety Evidence
Safety evidence often contains sensitive capability details. A capability evaluation for an ASL-3 model may reference specific dangerous capabilities, attack vectors, or containment weaknesses. Sharing this evidence broadly could itself create risk.
SWT3 clearing levels allow the same witness anchor to be shared at different levels of detail depending on the recipient:
- Level 0 -- Analytics: Full evaluation details including raw capability data. Appropriate for internal research teams conducting the evaluation.
- Level 1 -- Standard: Evaluation results without raw capability data. Appropriate for internal compliance teams reviewing governance processes.
- Level 2 -- Sensitive: Pass/fail outcomes with factor hashes replacing raw values. Appropriate for external auditors who need to verify that evaluations occurred without accessing capability details.
- Level 3 -- Classified: Numeric attestation only. Appropriate for public disclosure or regulatory reporting where the existence of an evaluation must be proven without revealing any capability information.
This is critical for ASL-3+ models where capability details are themselves sensitive. A policymaker can verify that a capability evaluation occurred (Level 3 anchor) without ever seeing what capabilities were evaluated. An auditor with appropriate clearance can verify the evaluation methodology (Level 2) without accessing raw results. The internal safety team retains the full evidence chain (Level 0) for their own records.
7. References
- Anthropic Responsible Scaling Policy (2023, updated 2025)
- UCT Registry -- 280 procedures across 9 namespaces
- SWT3 SDK Documentation -- Python, TypeScript, Go, Rust, C#, Ruby, Swift, Kotlin, MCP
- Anthropic: Core Views on AI Safety