Document Type
Operational Boundary Guide
Audience
Auditors, ISSMs, C3PAOs, Notified Bodies
Frameworks
EU AI Act + NIST AI RMF + SR 11-7
| Category |
Definition |
Example |
| SWT3 WITNESSES |
SWT3 provides tamper-evident cryptographic proof that the action occurred. The anchor is independently verifiable. |
AI-INF.1 proves an inference was logged with prompt/response hashes. |
| SHARED |
The organization performs the action; SWT3 provides the cryptographic evidence that it happened. Both are required. |
AI-GRD.1 proves guardrails were active, but the org must configure and maintain those guardrails. |
| DEPLOYER ONLY |
Entirely the organization's responsibility. SWT3 cannot witness qualitative judgment, organizational structure, or human cognition. |
SR 11-7 conceptual soundness requires human evaluation of statistical theory. |
| Requirement |
Owner |
SWT3 Procedure |
Notes |
| Art. 9(1): Establish risk management system |
DEPLOYER |
None |
Organizational governance. SWT3 cannot design a risk management framework. |
| Art. 9(4)(a): Risk measures operational |
SHARED |
AI-GRD.1, AI-GRD.2 |
Deployer configures guardrails. SWT3 proves they were active at inference time. |
| Art. 9(4)(b): Testing and validation |
SHARED |
AI-MDL.1, AI-MDL.3 |
Deployer runs validation. SWT3 proves model integrity and detects drift. |
| Art. 9(4)(c): Appropriate for intended purpose |
SHARED |
AI-ACC.1 |
Deployer defines access scope. SWT3 proves access was within scope. |
| Requirement |
Owner |
SWT3 Procedure |
Notes |
| Art. 12(1): Automatic event recording |
SWT3 |
AI-INF.1 |
Every anchor is an automatic log entry with millisecond precision. |
| Art. 12(2)(a): Input/output identification |
SWT3 |
AI-INF.1, AI-CHAIN.1 |
Prompt and response hashes captured. Multi-agent chains traced via cycle_id. |
| Art. 12(2)(b): Software version logging |
SWT3 |
AI-MDL.2, AI-MDL.6, AI-SKILL.1 |
Model version, adapter stack, and skill manifest captured per inference. |
| Art. 12(3)(c): Input data for matches |
SHARED |
AI-INF.1 (hashes only) |
SWT3 captures hashes, not raw input. If raw input storage is required, deployer must retain locally at Clearing Level 0 or in a separate database mapped to SWT3 fingerprints. |
| Art. 12(3)(d): Natural person identification |
SHARED |
AI-HITL.3 |
SWT3 records reviewer count and identity binding method. Deployer must implement the identity verification system. |
| Requirement |
Owner |
SWT3 Procedure |
Notes |
| Art. 14(1): Human-machine interface design |
DEPLOYER |
None |
SWT3 cannot attest to interface design quality or human comprehension. |
| Art. 14(4)(a): Override capability |
SHARED |
AI-HITL.2 |
SWT3 proves an override occurred. Deployer builds the override mechanism. |
| Art. 14(4)(b): Automation bias awareness |
DEPLOYER |
None |
Human cognition and training. SWT3 cannot measure whether a reviewer was subject to automation bias. |
| Art. 14(4)(e): Stop button and safe state |
SHARED |
AI-SAFE.1 |
SWT3 proves the mechanism was tested and safe state was confirmed. Deployer builds and maintains the stop mechanism. |
| Art. 14(5): Four-eyes verification (biometrics) |
SHARED |
AI-HITL.3 |
SWT3 records reviewer count and identity binding. Deployer must enforce that two independent, qualified persons performed the review. |
| AI RMF Function |
Owner |
SWT3 Procedure |
Notes |
| GOVERN 1.2: Roles and responsibilities |
SHARED |
AI-ID.1, AI-CHR.1, AI-TRUST.1 |
SWT3 proves agent identity and charter compliance. Deployer defines organizational roles. |
| GOVERN 1.4: Oversight mechanisms |
SHARED |
AI-HITL.1, AI-HITL.2, AI-HITL.3 |
SWT3 proves oversight actions occurred. Deployer designs and staffs the oversight program. |
| GOVERN 1.5: Ongoing monitoring plans |
SHARED |
AI-MDL.3, AI-GRD.1 |
SWT3 provides continuous monitoring evidence. Deployer writes and approves the monitoring plan. |
| GOVERN 1.7: Privacy and civil liberties |
SHARED |
AI-GRD.3, AI-FAIR.1 |
SWT3 proves PII redaction and fairness metrics. Deployer conducts impact assessments. |
| MAP 2.3: Fairness criteria |
SHARED |
AI-FAIR.2 |
SWT3 proves fairness thresholds were evaluated. Deployer defines the fairness criteria. |
| MANAGE 1.3: Deployment integrity |
SHARED |
AI-MDL.1, AI-MDL.2, AI-MDL.8 |
SWT3 proves model integrity, version, and registry status. Deployer maintains the approved registry. |
| MANAGE 3.2: Incident detection |
SHARED |
AI-VIO.1, AI-SEC.1 |
SWT3 proves violations and threats were detected. Deployer builds and executes incident response plans. |
| MANAGE 4.1: Post-deployment monitoring |
SHARED |
AI-HITL.2, AI-TOOL.1, AI-CHAIN.1, AI-SAFE.1 |
SWT3 proves operational events were logged. Deployer implements decommissioning, user feedback capture, and recovery procedures. |
| SR 11-7 Requirement |
Owner |
SWT3 Procedure |
Notes |
| Clear purpose and design documentation |
DEPLOYER |
None |
Qualitative documentation of model purpose. SWT3 cannot evaluate design intent. |
| Data quality assessment |
SHARED |
AI-DATA.1, AI-RAG.1 |
SWT3 proves data provenance and retrieval sources. Deployer evaluates representativeness. |
| Robustness testing and sensitivity analysis |
DEPLOYER |
None |
Deployer executes testing. SWT3 can witness results (via AI-MDL.3 drift detection) but cannot run the tests. |
| Model uncertainty accounting |
SHARED |
AI-EXPL.2, AI-HITL.2 |
SWT3 proves confidence scores were captured and overrides were logged. Deployer makes conservative adjustments. |
| Validation independence |
DEPLOYER |
None |
Organizational reporting lines. SWT3 cannot verify that a validator is independent from the development team. |
| Evaluation of conceptual soundness |
DEPLOYER |
None |
Human evaluation of statistical theory. SWT3 can prove that model weights have not been tampered with (AI-MDL.1) but cannot evaluate whether the underlying theory is sound. |
| Ongoing monitoring and process verification |
SHARED |
AI-INF.2, AI-MDL.3 |
SWT3 provides continuous performance and drift evidence. Deployer evaluates whether market conditions have changed. |
| Outcomes analysis and back-testing |
DEPLOYER |
None |
Deployer compares predictions to actual outcomes. SWT3 can witness confidence scores but cannot execute back-tests. |
| Firm-wide model inventory |
SHARED |
AI-MDL.2, AI-MDL.8 |
SWT3 proves which models are deployed and registry-checked. Deployer maintains the inventory. |
| Board and senior management oversight |
DEPLOYER |
None |
Governance structure. SWT3 cannot attend board meetings or verify management engagement. |
The following categories of requirements will never be addressable by a cryptographic witnessing protocol. They require human judgment, organizational structure, or qualitative assessment that no automated system can provide:
| Boundary |
Regulatory Examples |
Why SWT3 Cannot Witness This |
| Human cognition and psychology |
Art. 14(4)(b) automation bias, SR 11-7 expert judgment |
SWT3 records actions, not mental states. Whether a reviewer understood the output or was biased is unobservable by a protocol. |
| Organizational structure |
SR 11-7 validation independence, SR 11-7 board oversight |
Reporting lines, influence hierarchies, and management engagement are institutional constructs, not runtime events. |
| Qualitative evaluation |
SR 11-7 conceptual soundness, Art. 9(1) risk management design |
Evaluating whether a statistical theory is sound or a risk framework is comprehensive requires domain expertise and professional judgment. |
| Interface design |
Art. 14(1) human-machine interface, Art. 13(1) instructions for use |
Design quality is subjective and context-dependent. SWT3 operates at the data layer, not the presentation layer. |
| Active defense and prevention |
Art. 15(4) attack prevention, MANAGE 4.1 incident response |
SWT3 is detective (records that detection occurred) not preventive (does not block attacks). Active controls are the deployer's responsibility. |
| Process execution |
SR 11-7 back-testing, Art. 15 robustness testing, MANAGE 4.1 decommissioning |
SWT3 witnesses outcomes of processes but cannot execute the processes themselves. |