Audience: Notified Body technical assessors, conformity assessment leads, AI Act evaluation teams. This document defines the precise evidence boundaries of the SWT3 AI Witness Protocol for EU AI Act conformity assessment purposes.
1. What SWT3 Witnesses
SWT3 is an open witness protocol that produces per-inference cryptographic anchors. Each anchor records:
- Three compliance factors (factor_a, factor_b, factor_c) -- numeric values capturing operational metrics such as latency, token count, model identity hash, drift magnitude, or fairness scores
- A clearing level (0-3) -- controlling what data crosses the network boundary, from full analytics to classified (numeric factors only, model name hashed)
- A tamper-evident fingerprint -- a truncated SHA-256 hash computed from tenant, procedure, factors, and timestamp, verifiable by any party
SWT3 is an independent witness, not an enforcement mechanism. Think notary, not bodyguard. The protocol records that a governance-relevant event occurred, what its measurable properties were, and when it happened. It does not decide whether those properties are acceptable -- that judgment belongs to the Notified Body.
Anchors are immutable once minted. They can be revoked (with one of seven reason codes via AI-REV.1), but revocation creates a new anchor referencing the original -- the original record is never deleted or altered.
2. Article-by-Article Coverage Matrix
The following table maps EU AI Act articles to SWT3 evidence capabilities. Coverage Level indicates how much of the article's requirements SWT3 can address through automated evidence generation.
| EU AI Act Article | Requirement | SWT3 Coverage | Level | Notes |
|---|---|---|---|---|
| Art. 9 Risk Management |
Establish, implement, document, and maintain a risk management system throughout the AI system lifecycle | Witnesses bias metrics (AI-FAIR.1/2/3), drift detection (AI-BASE.1), behavioral violations (AI-VIO.1) | PARTIAL | Does NOT draft risk management systems or define risk appetite. SWT3 records evidence that risk-relevant metrics were measured; the NB must assess the adequacy of the surrounding risk management framework. |
| Art. 10 Data Governance |
Training, validation, and testing data sets subject to appropriate data governance and management practices | Witnesses training data provenance (AI-DATA.1/2/3/4), RAG context hashing (AI-RAG.1/2) | PARTIAL | Does NOT govern data collection, labeling, or validation processes. SWT3 records cryptographic evidence of data lineage; the NB must assess the quality and completeness of underlying data governance practices. |
| Art. 11 Technical Documentation |
Technical documentation drawn up before the AI system is placed on the market and kept up to date | Provides exportable evidence packages (Compliance Passport, OSCAL Assessment Results) | PARTIAL | Does NOT author the technical documentation narrative. SWT3 exports are recommended as supplementary evidence within the provider's Art. 11 documentation package. |
| Art. 12 Record-Keeping |
Automatic recording of events (logs) throughout the AI system lifetime, traceable to specific operations | Per-inference provenance hashing (AI-INF.1/2), model identity (AI-MDL.1/2), latency and token tracking | FULL | Continuous, automated, tamper-evident. Every inference produces a cryptographic anchor with timestamp, model identity, and operational metrics. Daily Merkle tree rollups provide batch integrity verification. |
| Art. 14 Human Oversight |
AI systems designed and developed to be effectively overseen by natural persons | Witnesses HITL verification events (AI-HITL.1/2), access control (AI-ACC.1), explainability output (AI-EXPL.1/2) | PARTIAL | Does NOT implement human oversight mechanisms. SWT3 records evidence that human oversight events occurred (review, approval, override); the NB must assess whether those mechanisms are appropriate and effective. |
| Art. 15 Accuracy, Robustness, Cybersecurity |
AI systems achieve appropriate levels of accuracy, robustness, and cybersecurity | Witnesses model performance metrics and drift (AI-BASE.1, AI-DRIFT.1/2, AI-PERF.1) | PARTIAL | Does NOT perform penetration testing, robustness evaluation, or adversarial testing. SWT3 records observed performance metrics over time; the NB must assess whether accuracy and robustness levels are appropriate for the intended purpose. |
| Art. 16 Provider Obligations / Post-Market |
Providers ensure post-market monitoring, take corrective action, and inform authorities of serious incidents | Anchor revocation with 7 reason codes (AI-REV.1), safe-state transitions (AI-SAFE.1) | PARTIAL | Does NOT manage corrective actions or draft serious incident reports. SWT3 provides cryptographic evidence of revocation events and safe-state transitions; the NB must assess the provider's corrective action process and incident reporting procedures. |
| Art. 50 Transparency / Content Marking |
AI-generated content marked in a machine-readable format, detectable as artificially generated | Witnesses C2PA manifest and watermark metadata (AI-MARK.1) | PARTIAL | Does NOT generate or apply watermarks. SWT3 records evidence that marking metadata was present at inference time; the NB must verify the marking mechanism itself. |
3. What SWT3 Does NOT Do
The following capabilities are explicitly outside the scope of the SWT3 protocol. This list is provided so that NB assessment teams can plan their evaluation accordingly and allocate resources to areas where traditional assessment methods are required.
- Does not draft, author, or maintain technical documentation (Art. 11 narrative). SWT3 exports are evidence artifacts, not the documentation itself.
- Does not design or implement AI Management Systems (AIMS). SWT3 witnesses the outputs of an AIMS; it does not replace one.
- Does not make conformity assessment decisions. Only a Notified Body can determine conformity. SWT3 provides evidence; it does not interpret it.
- Does not apply CE marking. CE marking is the provider's declaration of conformity, outside the scope of any evidence protocol.
- Does not perform Quality Management System audits. SWT3 does not assess organizational processes, staffing, or management controls.
- Does not replace Notified Body assessment judgment. Professional judgment on adequacy, appropriateness, and completeness remains with the NB.
- Does not generate or enforce policies. SWT3 records evidence of policy-relevant events. Policy creation and enforcement are the provider's responsibility.
- Does not operate as a security product (firewall, IDS, WAF, etc.). SWT3 is a compliance evidence protocol, not a security enforcement mechanism.
4. Evidence Boundary Taxonomy
SWT3 evidence falls into three categories. Understanding these boundaries is essential for NB teams to determine where SWT3 evidence is sufficient and where traditional assessment methods must supplement it.
| Boundary | Definition | NB Action | Example |
|---|---|---|---|
| FULL | SWT3 produces complete, verifiable evidence for this requirement. The evidence is continuous, automated, and tamper-evident. | Verify the anchor chain independently using the public verify endpoint. Validate completeness against the requirement's assessment criteria. | Art. 12 record-keeping: every inference is automatically recorded with a cryptographic anchor, model identity, and timestamp. |
| PARTIAL | SWT3 produces supporting evidence, but the NB must assess the surrounding process and documentation to determine full conformity. | Use SWT3 evidence as one input to the assessment. Evaluate the provider's processes, policies, and organizational controls independently. | Art. 14 human oversight: SWT3 records that a human review occurred (AI-HITL.1), but the NB must assess whether the oversight mechanism is appropriate for the risk level. |
| NOT COVERED | SWT3 does not produce evidence for this requirement. The NB relies entirely on traditional assessment methods. | Apply standard conformity assessment techniques: documentation review, interviews, on-site inspection, testing. | CE marking eligibility, QMS organizational processes, risk appetite determination. |
5. What the NB Must Still Assess Independently
Even where SWT3 coverage is FULL or PARTIAL, the following areas require independent NB assessment. SWT3 evidence can inform these assessments but cannot substitute for them.
- Adequacy of the provider's risk management system (Art. 9). SWT3 records risk-relevant metrics (bias, drift, violations), but whether the provider's risk management system is comprehensive, proportionate, and continuously maintained is an organizational judgment.
- Completeness and accuracy of technical documentation narrative (Art. 11). SWT3 exports provide structured evidence data. The narrative explaining system purpose, design choices, limitations, and intended use must come from the provider.
- Appropriateness of human oversight mechanisms (Art. 14). SWT3 records that oversight events occurred. Whether those mechanisms are effective, proportionate to the risk, and properly staffed is an NB determination.
- Organizational QMS processes. Quality management systems, internal audit schedules, management review cycles, and corrective action processes are organizational controls outside the protocol's scope.
- CE marking eligibility. The provider's declaration of conformity and CE marking decision are legal acts that no evidence protocol can make on behalf of the provider.
- Post-market monitoring plan design (Art. 16). SWT3 provides evidence of monitoring activity (drift, revocation, safe-state). Whether the monitoring plan is adequately designed for the system's risk profile is an NB judgment. The plan itself -- not just the evidence of its execution -- must be assessed.
6. Clearing Levels and Data Sovereignty
SWT3 implements four clearing levels that control what data crosses the network boundary. This is relevant to NB teams evaluating data protection and sovereignty claims.
| Level | Name | What Crosses the Boundary | Data Sovereignty Implication |
|---|---|---|---|
| 0 | Analytics | Hashes, factors, model ID, prompt/response length, latency | No raw content transmitted. Metadata only. |
| 1 | Standard | Hashes, factors, model ID | Raw prompts and responses never leave customer infrastructure. Length and latency metrics are stripped. |
| 2 | Sensitive | Hashes and factors only | Model identity and all metadata stripped. Only cryptographic hashes and numeric compliance factors are transmitted. |
| 3 | Classified | Numeric factors only, model name hashed | Minimal data transmitted: only numeric factors and hashed model identifiers reach the platform. No plaintext model names or provider metadata. For fully air-gapped deployments (Sovereign tier), anchors remain entirely within the customer's infrastructure via offline .pulse bundles. |
7. How Pilot Evidence Maps to Conformity Assessment
Practical guidance for NB teams integrating SWT3 evidence into their conformity assessment workflow:
Compliance Passport as Art. 11 Supplementary Evidence
The Compliance Passport export (available as HTML, HMAC-signed JSON, or W3C Verifiable Credential) provides a structured summary of compliance posture. We recommend including it as an appendix to the provider's Art. 11 technical documentation package. The HMAC-signed JSON format is machine-verifiable. The W3C VC format is self-verifiable using the did:web:sovereign.tenova.io DID document.
OSCAL Assessment Results for Structured Findings
The OSCAL Assessment Results export is validated against the NIST oscal-cli reference implementation. NB teams familiar with OSCAL can import these results into their existing assessment tooling for cross-framework analysis.
Independent Anchor Verification
The public verify endpoint at sovereign.tenova.io/verify allows any party to independently validate an anchor's fingerprint. Verification runs entirely in the browser using client-side SHA-256 -- the platform does not participate in the verification computation. NB teams can verify any anchor at any time without platform cooperation.
Temporal Proof via Fingerprint
Each anchor fingerprint is computed from a millisecond-precision timestamp. The fingerprint proves that evidence existed at a specific point in time. Combined with daily Merkle tree rollups, the NB can verify that the evidence chain has not been retroactively altered.
8. Related Documents
- NB Pilot Package -- commercial scope, pricing, timeline, and deliverables for the 10-day evaluation engagement
- Pilot Program Guide -- technical setup, onboarding steps, and architecture overview
- Pilot Onboarding Checklist -- step-by-step checklist from agreement signature to first anchor
- Pilot FAQ -- expanded FAQ for Notified Bodies, C3PAOs, and enterprise evaluators
- Pilot Agreement -- binding terms and conditions for the evaluation engagement
- EU AI Act Assessment Walkthrough -- full article-by-article assessment walkthrough with SWT3 evidence mapping
- Conformity Assessment Evidence Guide -- detailed conformity assessment evidence guide for high-risk AI systems