Who this is for: Safety teams and compliance officers at frontier AI developers (models trained on 1026+ FLOPs), legal counsel at AI labs with >$500M annual revenue, and infrastructure teams responsible for transparency reporting, incident response, and record retention.

Effective now. SB 53 took effect January 1, 2026. Penalties up to $1,000,000 per violation. "Large" frontier developer obligations (>$500M revenue) include quarterly risk assessment summaries to Cal OES. Anthropic has already published its compliance framework.

Contents

1. What SB 53 Requires 2. Obligation-to-Procedure Mapping 3. Detailed Procedure Cards 4. Record Retention and Merkle Proofs 5. Recommended SWT3 Profiles 6. Quick Reference 7. Quick Start 8. References

1. What SB 53 Requires

The Transparency in Frontier Artificial Intelligence Act (SB 53) applies to developers who have trained, or initiated the training of, a frontier model -- defined as any AI model trained using more than 1026 floating-point operations (FLOPs).

A "large" frontier developer (annual gross revenue exceeding $500 million) faces additional requirements including quarterly risk assessment summaries to the California Office of Emergency Services (Cal OES).

SB 53 imposes five core obligations:

ObligationRequirementTimeline
Frontier AI FrameworkPublish a documented framework describing how national and international AI standards are incorporated into development processesBefore deploying a frontier model
Transparency ReportsIssue transparency reports describing model capabilities, intended uses, limitations, and risk assessment results before deploying new or substantially modified frontier modelsBefore each deployment or substantial modification
Catastrophic Risk AssessmentsConduct and document assessments of catastrophic risk resulting from internal use of frontier models. Large developers must transmit summaries to Cal OES.Quarterly (or per developer-specified schedule)
Critical Incident ReportingNotify Cal OES of critical safety incidents within 15 days of discovery, or within 24 hours if an incident poses imminent danger15 days (standard) / 24 hours (imminent danger)
Whistleblower ProtectionsMaintain anonymous reporting channels for catastrophic risk concerns. Retain all unredacted documents for 5 years. No retaliation against reporters.Continuous; 5-year retention window

2. Obligation-to-Procedure Mapping

Each SB 53 obligation maps to SWT3 witness procedures that produce cryptographically anchored evidence of compliance.

SB 53 ObligationSWT3 ProcedureWhat It WitnessesEvidence Produced
Frontier AI FrameworkAI-GOV.1Acceptable use policy attestationFactor A: policy version, Factor B: compliance status, Factor C: review date
AI-GOV.6Risk management scope definitionFactor A: scope boundary, Factor B: risk tiers, Factor C: responsible party
AI-TRANS.1Transparency disclosureFactor A: disclosure method, Factor B: content hash, Factor C: recipient context
Transparency ReportsAI-MDL.1Model weight integrity verificationFactor A: model identifier, Factor B: weight hash, Factor C: version
AI-MDL.2Model version trackingFactor A: previous version, Factor B: current version, Factor C: change summary
AI-SBOM.1AI software bill of materialsFactor A: component count, Factor B: SBOM hash, Factor C: format
AI-INF.1Inference provenanceFactor A: model, Factor B: provider, Factor C: clearing level
AI-EXPL.1Explanation generationFactor A: explanation method, Factor B: confidence, Factor C: factors cited
Catastrophic Risk AssessmentsAI-RISK.1Risk identification and categorizationFactor A: risk category, Factor B: severity, Factor C: mitigation status
AI-IMPACT.1Societal impact assessmentFactor A: assessment scope, Factor B: risk rating, Factor C: review authority
AI-SAFE.1Catastrophic risk and safe state verificationFactor A: risk scenario, Factor B: mitigation status, Factor C: safe state definition
AI-REDTEAM.1Adversarial test campaignFactor A: test scope, Factor B: findings count, Factor C: severity distribution
Critical Incident ReportingAI-INCIDENT.1Incident detection and classificationFactor A: incident type, Factor B: severity, Factor C: detection method
AI-IR.1Incident response executionFactor A: response plan, Factor B: containment status, Factor C: timeline
AI-VIO.1Violation and whistleblower reportingFactor A: report channel, Factor B: category, Factor C: acknowledgment status
Record RetentionAI-AUDIT.1Audit log integrity verificationFactor A: log source, Factor B: integrity hash, Factor C: retention period
AI-AUDIT.2External timestamp attestationFactor A: TSA provider, Factor B: RFC 3161 token, Factor C: digest algorithm
AI-LOG.1Logging pipeline attestationFactor A: log destination, Factor B: pipeline hash, Factor C: rotation policy

3. Detailed Procedure Cards

AI-SAFE.1

Catastrophic Risk and Safe State Verification

SB 53 requires: Large frontier developers must assess catastrophic risk from internal use of frontier models and transmit summaries to Cal OES quarterly.

How SWT3 addresses it: The witness_safe_state() call captures the risk scenario evaluated, the current mitigation status, and the defined safe state. Each quarterly assessment generates a timestamped anchor that proves the assessment occurred and documents its findings. The anchor chain creates a longitudinal record of risk evolution.

What to show the examiner

Filter the witness ledger for AI-SAFE.1 anchors at quarterly intervals. Factor A identifies the risk scenario. Factor B shows mitigation status. Factor C defines what "safe state" means for that scenario. Cross-reference with AI-REDTEAM.1 anchors to show that adversarial testing validated the risk assessment.

AI-INCIDENT.1

Incident Detection and Classification

SB 53 requires: Frontier developers must notify Cal OES of critical safety incidents within 15 days of discovery, or within 24 hours if the incident poses imminent danger to public safety.

How SWT3 addresses it: The witness_incident() call records the incident type, severity classification, and detection method at the moment of discovery. The anchor timestamp establishes when the incident was detected, creating an immutable timeline for the 15-day (or 24-hour) reporting window.

What to show the examiner

AI-INCIDENT.1 anchor timestamps establish the discovery date. Pair with AI-IR.1 anchors to show the incident response timeline. The delta between AI-INCIDENT.1 (detection) and the Cal OES notification must be within 15 days (standard) or 24 hours (imminent danger). Factor B severity classification determines which reporting window applies.

AI-SBOM.1

AI Software Bill of Materials

SB 53 requires: Transparency reports must describe model capabilities, intended uses, and limitations. An AI-SBOM documents the model's component composition.

How SWT3 addresses it: The witness_sbom() call captures the component count, a SHA-256 hash of the full SBOM, and its format (SPDX, CycloneDX). This creates a verifiable record that the model's composition was documented before deployment.

What to show the examiner

AI-SBOM.1 anchors with timestamps predating the model deployment prove that component analysis was completed before release. Factor B (SBOM hash) allows the examiner to verify the SBOM has not been altered post-deployment.

AI-REDTEAM.1

Adversarial Test Campaign

SB 53 requires: Risk assessments must evaluate catastrophic risk scenarios. Adversarial testing is a standard method for identifying frontier model risks.

How SWT3 addresses it: The witness_redteam() call records the test scope, total findings count, and severity distribution. Each red team campaign produces an anchor that proves testing occurred, how many issues were found, and their severity breakdown.

What to show the examiner

AI-REDTEAM.1 anchors should precede AI-SAFE.1 (risk assessment) anchors, showing that adversarial testing informed the risk evaluation. Factor C (severity distribution) shows the breakdown of findings by severity level.

AI-VIO.1

Violation and Whistleblower Reporting

SB 53 requires: Employers must maintain anonymous channels for reporting concerns regarding catastrophic risk and may not retaliate against employees or contractors who make such reports.

How SWT3 addresses it: The witness_violation() call records that a report was received through the anonymous channel, its category, and that acknowledgment was issued. The anchor proves the reporting mechanism exists and is functioning, without revealing the reporter's identity.

What to show the examiner

AI-VIO.1 anchors prove the anonymous reporting channel is active. Factor A (report channel) identifies the mechanism. Factor C (acknowledgment status) proves reports are being processed. The absence of AI-VIO.1 anchors may itself be a finding if no channel exists.

AI-AUDIT.2

External Timestamp Attestation

SB 53 requires: Unredacted information must be retained for five years. Records must be demonstrably intact.

How SWT3 addresses it: The witness_external_timestamp() call records an RFC 3161 timestamp from an external Time Stamping Authority (TSA), providing a third-party attestation of when the record existed. This creates a chain of trust independent of the producing organization.

What to show the examiner

AI-AUDIT.2 anchors contain RFC 3161 tokens from an independent TSA. Factor B contains the token. Combined with the SWT3 daily Merkle rollup, this creates two independent layers of temporal proof: the SWT3 anchor timestamp and the RFC 3161 external attestation.

AI-MDL.1

Model Weight Integrity

SB 53 requires: Transparency reports must describe model capabilities and be issued before deploying new or substantially modified frontier models.

How SWT3 addresses it: The witness_model_weights() call captures the model identifier, a SHA-256 hash of the model weights, and the version identifier. Any modification to the model weights produces a different hash, creating a verifiable record that the model described in the transparency report matches the model actually deployed.

What to show the examiner

AI-MDL.1 anchors with matching weight hashes (Factor B) before and after deployment prove the deployed model matches the one described in the transparency report. A hash mismatch indicates a substantially modified model that requires a new report.

4. Record Retention and Merkle Proofs

SB 53 requires frontier developers to retain unredacted information for five years. SWT3 provides two layers of evidence integrity for long-term retention:

Layer 1: Witness Anchor Chain

Every SWT3 Witness Anchor contains a SHA-256 fingerprint computed from the tenant, procedure, factors, and timestamp. Anchors are immutable once minted. Retention periods are tier-dependent: Enclave retains for 7 years, Sovereign retains indefinitely. Both exceed the SB 53 five-year requirement.

Layer 2: Daily Merkle Rollup

At 00:01 UTC daily, SWT3 computes a Merkle root from all anchors minted that day. The Merkle tree uses domain-separated hashing (SWT3:LEAF: and SWT3:NODE: prefixes) to prevent second-preimage attacks. Individual anchors can be proven against the daily root via inclusion proofs at /api/v1/merkle/proof?fingerprint=xxx.

Layer 3: RFC 3161 External Timestamps

AI-AUDIT.2 anchors can include RFC 3161 timestamps from an external TSA, providing a third-party attestation that the Merkle root existed at the claimed time. This creates a chain of trust that does not depend on the SWT3 infrastructure itself.

Together, these three layers ensure that records are tamper-evident, externally verifiable, and retainable well beyond the five-year window.

5. Recommended SWT3 Profiles

ProfileApplicabilitySB 53 CoverageCommand
nist-ai-rmfAny frontier developer80 procedures covering NIST AI RMF. Includes all risk, transparency, and governance procedures needed for SB 53.swt3 init --profile nist-ai-rmf
owasp-agenticAgentic AI systemsRuntime containment procedures. Relevant for frontier models deployed as autonomous agents.swt3 init --profile owasp-agentic

6. Quick Reference

Examiner QuestionWhere to Look
Have you published a Frontier AI Framework?AI-GOV.1 + AI-GOV.6 + AI-TRANS.1 anchors. Factor B in AI-TRANS.1 contains the content hash of the published framework.
Did you issue a transparency report before this deployment?AI-MDL.1 + AI-MDL.2 + AI-SBOM.1 anchors with timestamps predating the first AI-INF.1 anchor for the new model version.
When was the last catastrophic risk assessment?AI-SAFE.1 + AI-RISK.1 + AI-REDTEAM.1 anchors. Filter by quarter. Gap of >90 days between AI-SAFE.1 anchors indicates a missed quarterly assessment.
How quickly did you report the last critical incident?Delta between AI-INCIDENT.1 timestamp (discovery) and the Cal OES notification. Must be within 15 days (standard) or 24 hours (imminent danger, determined by Factor B severity).
Do you have an anonymous whistleblower channel?AI-VIO.1 anchors prove the channel exists and is processing reports. Absence of AI-VIO.1 anchors may indicate no channel is operational.
Can you prove 5-year record integrity?SWT3 Merkle rollups + AI-AUDIT.2 (RFC 3161 external timestamps). Inclusion proofs at /api/v1/merkle/proof. Enclave tier retains 7 years, Sovereign unlimited.
Were any third-party evaluators used?AI-REDTEAM.1 Factor A (test scope) documents whether testing was internal or external. AI-AUDIT.2 provides independent timestamp verification.

7. Quick Start

# Install the SDK
pip install swt3-ai

# Initialize with the NIST AI RMF profile (covers all SB 53 obligation areas)
swt3 init --profile nist-ai-rmf --tenant YOUR_TENANT

# Run the demo to see witness anchors generated
python -m swt3_ai.demo

# Or use TypeScript
npm install @tenova/swt3-ai
npx swt3-init --profile nist-ai-rmf

Full SDK documentation: sovereign.tenova.io/docs

Create a free account: sovereign.tenova.io/signup

8. References