Audience: AI governance teams, IVO candidates, Virginia JCOTS commissioners, C3PAOs expanding into AI verification, compliance officers evaluating independent AI verification, and legal counsel advising on AI safety verification.
Status: SB 384/HB 797 signed by Governor Spanberger on April 13, 2026. Bipartisan vote: House 84-14, Senate 40-0. Directs JCOTS to evaluate a framework for Independent Verification Organizations (IVOs) that independently verify whether AI systems meet safety standards. Study mandate with legislative framework implications.
Contents
1. What Virginia Requires 2. What an IVO Does 3. SWT3 as IVO Infrastructure 4. Obligation-to-Procedure Mapping 5. Procedure Cards 6. Quick Reference 7. Quick Start 8. References1. What Virginia Requires
Virginia SB 384/HB 797 directs the Joint Commission on Technology and Science (JCOTS) to study and evaluate developing a framework for Independent Verification Organizations (IVOs). The core concept: independent bodies -- not the AI developer, not the deployer -- that verify whether AI systems meet safety standards.
The legislation passed with overwhelming bipartisan support. The Senate voted 40-0 and the House voted 84-14, reflecting broad consensus that independent AI verification is a necessary governance function. Governor Spanberger signed the bill on April 13, 2026.
This bill represents a deliberate pivot in Virginia's approach to AI governance. Former Governor Youngkin vetoed the broader HB 2094 in 2025, which attempted comprehensive AI regulation. Governor Spanberger took a more targeted approach -- rather than regulating AI systems directly, the legislation focuses on building the verification infrastructure that makes AI regulation enforceable.
While SB 384/HB 797 is a study bill, it lays the groundwork for mandatory independent verification. JCOTS will evaluate what an IVO framework should include, what standards IVOs should verify against, and how IVOs should produce evidence for regulators. Organizations that invest in IVO-compatible infrastructure now will be positioned when the framework transitions from study to mandate.
2. What an IVO Does
The IVO model centers on four capabilities that distinguish it from self-assessment and internal audit:
1. Independent Verification
An IVO verifies that AI system outputs match claimed capabilities. The verification must be reproducible by third parties -- an IVO's conclusions should be independently confirmable by regulators, auditors, or other IVOs without relying on the original verifier's assertions.
2. Safety Standards Testing
IVOs test AI systems against recognized safety benchmarks. This includes performance under adversarial conditions, bias evaluation across protected classes, robustness to distribution shift, and safe-state recovery when failures occur. The benchmarks must be public and well-defined.
3. Continuous Monitoring
IVO assessments are ongoing, not one-time. AI systems change through retraining, fine-tuning, and data drift. An IVO must detect when a previously verified system degrades below safety thresholds and produce evidence of that degradation for stakeholders.
4. Evidence Production
IVOs generate structured, verifiable evidence for regulators. The evidence must be portable (not locked to a proprietary platform), integrity-protected (tamper-evident), and machine-readable (enabling automated regulatory review at scale).
3. SWT3 as IVO Infrastructure
SWT3's protocol architecture directly implements the IVO model. Each core IVO capability maps to a specific protocol feature:
Fingerprint Verification as Independent Verification
SWT3-SPEC Section 11 defines a deterministic fingerprint algorithm: SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]. Any party can recompute this fingerprint using standard POSIX tools. No proprietary software, no authentication, no account required. This is the cryptographic foundation of independent verification -- the IVO's conclusions are independently confirmable by anyone with the input components.
Witness Anchors as Independent Attestation
SWT3 Witness Anchors are cryptographic attestations produced by an independent witness engine, not self-attestations by the AI system under evaluation. The witness engine observes inference behavior, computes evidence factors, and mints an immutable anchor. The AI system cannot forge, suppress, or alter its own anchors.
Evidence Separation
The SWT3 protocol separates evidence production from evidence consumption. Any assessor tool that implements the SWT3 fingerprint algorithm can consume and verify SWT3 anchors. This prevents vendor lock-in and enables a competitive IVO ecosystem where multiple organizations verify evidence using the same protocol.
Conformity Evidence Packages
SWT3-SPEC Section 24 defines the Conformity Evidence Package (CEP) format -- self-contained JSON bundles with integrity verification via packageHash and optional Merkle proofs. CEPs are exactly what an IVO would produce: portable, self-verifying evidence packages that regulators can evaluate without access to the original verification platform.
Auditor Display Standard
SWT3-SPEC Section 23 defines how any tool must present SWT3 anchors to auditors. This ensures that regardless of which IVO produced the evidence, the presentation format is consistent, comparable, and interpretable. Regulators evaluating evidence from multiple IVOs see a uniform format.
4. Obligation-to-Procedure Mapping
| IVO Capability | SWT3 Procedure / Feature | Evidence Produced |
|---|---|---|
| Independent verification | SWT3 Fingerprint Algorithm (Section 7) | SHA-256 recomputation by any party |
| Safety testing | AI-SAFE.1, AI-PERF.1, AI-ROBUST.1 | Safe-state recovery, performance metrics, robustness thresholds |
| Bias and fairness evaluation | AI-FAIR.1 | Bias disparity ratio, protected class coverage |
| Transparency assessment | AI-TRANS.1, AI-EXPL.1 | Disclosure type, explanation method |
| Continuous monitoring | AI-DRIFT.1, AI-LCM.1 | Drift detection intervals, lifecycle version transitions |
| Audit chain integrity | AI-AUDIT.1 | Tamper detection evidence, chain continuity |
| Inference provenance | AI-INF.1 | Model hash, prompt hash, response hash |
| Incident detection | AI-INCIDENT.1 | Severity, incident type, notification timestamp |
| Evidence packaging | Conformity Evidence Package (Section 24) | Self-contained JSON, packageHash, Merkle proof |
5. Procedure Cards
Independent Verification Without Trust
The core IVO capability. Any party can recompute a SHA-256 fingerprint from its input components using standard POSIX tools. No account, no proprietary software, no authentication. The fingerprint formula is public and deterministic:
This is the foundation of the IVO model. An IVO's verification is not an assertion of authority -- it is a cryptographic proof that anyone can independently confirm. Two IVOs evaluating the same anchor will always produce the same fingerprint.
Select any anchor from the witness ledger. Extract the input components (tenant, procedure, factors, timestamp). Recompute the fingerprint using the command above. Confirm it matches the anchor's fingerprint field. This is the IVO's primary verification mechanism -- if it matches, the evidence is authentic.
Safety Standards Testing
IVOs verify that AI systems meet recognized safety benchmarks. Three SWT3 procedures create a layered safety evidence chain:
- AI-SAFE.1 -- witnesses safe-state recovery capability. Factor A records the safe-state type, Factor B records recovery time.
- AI-PERF.1 -- witnesses performance against defined thresholds. Factor A records the metric name, Factor B records the measured value.
- AI-ROBUST.1 -- witnesses robustness under adversarial or distribution-shift conditions. Factor A records the test type, Factor B records the degradation measure.
Together, these three procedures answer the question every IVO must address: does this AI system perform safely, reliably, and resiliently under real-world conditions?
Cross-reference timestamps across AI-SAFE.1, AI-PERF.1, and AI-ROBUST.1 anchors to verify testing cadence. Look specifically for AI-SAFE.1 anchors showing recovery capability -- these demonstrate the system can fail gracefully, which is a core IVO safety requirement.
Continuous Monitoring Evidence
IVOs must provide ongoing assessment, not one-time certification. Two SWT3 procedures create continuous monitoring evidence:
- AI-DRIFT.1 -- witnesses drift detection events. Factor A records the drift metric, Factor B records the measured deviation from baseline.
- AI-LCM.1 -- witnesses lifecycle transitions (deployment, retraining, retirement). Factor A records the lifecycle event type, Factor B records the version identifier.
Continuous monitoring is what distinguishes an IVO from a traditional auditor. A one-time assessment tells you the system was safe on the day it was tested. Continuous monitoring tells you whether it is still safe today.
Verify that AI-DRIFT.1 anchors are minted at regular intervals -- gaps in the drift detection timeline indicate monitoring lapses. AI-LCM.1 anchors should show version transitions; if the model version changes without a corresponding AI-LCM.1 anchor, the lifecycle chain is broken.
Portable Evidence for Regulators
SWT3-SPEC Section 24 defines the Conformity Evidence Package (CEP) format. A CEP is a self-contained JSON bundle that includes all anchors, metadata, and integrity verification needed for regulatory review:
- packageHash -- SHA-256 of the package contents, enabling tamper detection
- Anchor array -- all relevant SWT3 Witness Anchors with full factor data
- Merkle proof -- optional inclusion proof linking individual anchors to the daily Merkle root
- Metadata -- tenant, framework, date range, procedure coverage
CEPs are what an IVO delivers to regulators. They are portable (JSON), self-verifying (packageHash), and machine-readable (structured schema). A regulator can evaluate a CEP without access to the IVO's platform.
Verify the packageHash by recomputing SHA-256 over the package contents. Spot-check at least one fingerprint from the anchor array using the verification command. If a Merkle proof is included, verify inclusion against the published daily root.
6. Quick Reference
| Examiner Question | Where to Look |
|---|---|
| How do you verify AI system claims independently? | SWT3 fingerprint recomputation -- any party, any tool, deterministic SHA-256 |
| What safety benchmarks do you test against? | AI-SAFE.1 (safe state), AI-PERF.1 (performance), AI-ROBUST.1 (robustness) anchors |
| How do you demonstrate continuous monitoring? | AI-DRIFT.1 anchor timeline -- regular intervals, no gaps in drift detection |
| Can regulators verify your evidence without your platform? | Conformity Evidence Package (CEP) -- self-contained JSON with packageHash |
| How do you ensure evidence presentation is consistent? | SWT3 Auditor Display Standard (SWT3-SPEC Section 23) -- uniform format across IVO tools |
| How do you detect when a verified system degrades? | AI-DRIFT.1 + AI-LCM.1 lifecycle chain -- version transitions, drift thresholds, incident anchors |
7. Quick Start
Python
from swt3_ai import Witness
witness = Witness(
api_key="your-api-key",
tenant_id="your-tenant-id",
profile="defense-govcon"
)
TypeScript
import { Witness } from '@tenova/swt3-ai';
const witness = new Witness({
apiKey: 'your-api-key',
tenantId: 'your-tenant-id',
profile: 'defense-govcon'
});