SWT3 Assessor Hot Sheet

AI Compliance Evidence -- Verify, Understand, Map

Version 1.0 | July 2026 | Tenable Nova LLC | sovereign.tenova.io

Side A -- For the Assessor

1. Verify It Yourself (30 seconds)

You do not need to trust the client's system. The developer or CISO will provide you with one or more anchor strings from their AI system. Take any one and paste it into the public verification endpoint below. No account required. No software to install.

sovereign.tenova.io/verify

Paste the full anchor string. The verifier will decompose it into its constituent fields and confirm the cryptographic fingerprint matches the original witness event. If it resolves, the evidence is intact and has not been tampered with since minting.

Independence matters. The verification endpoint is public infrastructure. It uses the same cryptographic formula as the SDK that minted the anchor. You are verifying against the protocol, not the vendor. SWT3 is an open protocol (Apache 2.0, source on GitHub) published by Tenable Nova LLC with crosswalks to NIST, ISO, and EU frameworks.

2. What You Just Verified

An SWT3 Witness Anchor is a cryptographic proof that an AI system was evaluated against a specific compliance procedure at a specific time and received a deterministic verdict. Here is how to read one:

SWT3-E-VULTR-AI-INF1-PASS-1773316622-96b7d56c0245

ProtocolSWT3 -- Sovereign Witness Traceability v3

TierE = Enclave (dedicated infrastructure)

ProviderVULTR -- hosting environment

NamespaceAI -- AI Governance domain

ProcedureINF1 -- Inference Provenance (AI-INF.1)

VerdictPASS -- compliance confirmed at evaluation time

Epoch1773316622 -- Unix timestamp (exact second)

Fingerprint96b7d56c0245 -- SHA-256 truncated (12 hex chars)

The fingerprint is computed from: tenant identity + procedure ID + three evaluation factors + timestamp. It cannot be forged without access to the original inputs at the original time.

A failing anchor looks the same: SWT3-E-VULTR-AI-GRD1-FAIL-1773316622-a1b2c3d4e5f6. The verdict field changes; everything else is identical. Both PASS and FAIL anchors are independently verifiable. Failures in the ledger demonstrate the system is honest, not optimistic.

3. Your Framework, Our Evidence

Each SWT3 procedure maps to the controls you are assessing. Find your framework below and note which procedures satisfy which requirements.

Your Requirement	SWT3 Procedure	What It Proves
EU AI ACT (High-Risk)
Art. 9(2)(a) -- Risk management system	AI-GRD.1	Safety guardrails were active at inference time
Art. 10(2)(a) -- Data governance	AI-DATA.1	Training data provenance is documented
Art. 10(2)(f) -- Bias examination	AI-FAIR.1	Disparity ratio measured across protected groups
Art. 12(1) -- Automatic logging	AI-INF.1	Every inference was cryptographically fingerprinted
Art. 13(1) -- Transparency	AI-EXPL.1	Explanation generated with AI output
Art. 14(1) -- Human oversight	AI-HITL.1	Human reviewed and approved high-risk decision
NIST 800-53 / AI RMF
SI-4 -- System monitoring	AI-INF.1	Continuous inference monitoring with provenance
MEASURE 2.5 -- AI system trustworthiness	AI-INF.1, AI-FAIR.1	Trustworthiness metrics captured per inference
MANAGE 4.1 -- Risk treatment	AI-GRD.1	Safety controls confirmed active
GOVERN 1.1 -- Accountability structures	AI-HITL.1	Human oversight exercised and recorded
CMMC LEVEL 2
CA.L2-3.12.1 -- Security assessments	AI-INF.1, AI-GRD.1	AI controls assessed continuously, not annually
SI.L2-3.14.6 -- Monitor communications	AI-INF.1	AI inference traffic monitored and recorded
SR 11-7 (Model Risk Management)
Effective challenge -- independent review	AI-FAIR.1, AI-EXPL.1	Model outputs independently evaluated for bias and explainability
Ongoing monitoring	AI-INF.1, AI-DRIFT.2	Continuous monitoring with drift detection thresholds

Full crosswalk (108 procedures across 31 frameworks): Assessor Evidence Matrix

4. Full Audit Trail

If you need to examine evidence beyond individual anchors, the organization's audit portal provides:

Verdict History -- every evaluation result for this AI system over time, filterable by procedure and date range
Lifecycle Chains -- linked sequences of anchors showing how the system progressed through development, testing, deployment, and monitoring phases
Drift Trends -- visual indicators of model behavior change with consequence-mapped thresholds (AI-DRIFT.2)
Compliance Passport -- one-page exportable summary of current posture across all assessed procedures

Request a demo portal walkthrough: sovereign.tenova.io/axm_audit_demo

5. Go Deeper

Assessment Playbook -- 7-step methodology for conducting a full SWT3-based assessment
Evidence Matrix -- every regulatory requirement mapped to the specific artifact that satisfies it
UCT Registry -- complete catalog of 108 procedures across 56 namespaces
Protocol Specification -- technical details of the SWT3 witness format
Protocol Source -- open (Apache 2.0), independent of any single vendor implementation

Join the SWT3 Assessor Network

Get early access to assessment tooling, framework updates, and the assessor directory.

Request Access

Side B -- For the Developer / CISO

1. Match Your Framework

Before the meeting, identify which anchors matter for your specific assessment. Pull evidence for these procedures based on what you are being assessed against. If you see procedures you haven't implemented yet, check the SDK quickstart for integration steps -- better to address gaps before the meeting than explain them during.

If Your Assessment Is...	Focus On These Anchors
EU AI Act (Notified Body)	AI-INF.1, AI-GRD.1, AI-FAIR.1, AI-DATA.1, AI-EXPL.1, AI-HITL.1
NIST 800-53 / FedRAMP (3PAO/C3PAO)	AI-INF.1, AI-GRD.1, AI-HITL.1, AI-SEC.1, AI-ACC.1
CMMC Level 2 (C3PAO)	AI-INF.1, AI-GRD.1, AI-ACC.1
SR 11-7 (OCC/Fed Examiner)	AI-INF.1, AI-FAIR.1, AI-EXPL.1, AI-DRIFT.2, AI-MDL.5
NIST AI RMF (Internal/External)	AI-INF.1, AI-GRD.1, AI-FAIR.1, AI-HITL.1, AI-DATA.1
ISO 42001 (Certification Body)	AI-INF.1, AI-GRD.1, AI-FAIR.1, AI-EXPL.1, AI-DATA.1, AI-HITL.1

2. Pre-Meeting Checklist

Export your Compliance Passport -- Go to Settings or call GET /api/v1/passport/export. This is the one-page posture summary the assessor can keep.
Verify your own anchors -- Go to your ledger (/ledger), filter by the procedures in your framework row above, and copy 2-3 recent anchor strings. Paste them into sovereign.tenova.io/verify. Confirm they resolve. Do not walk in untested.
Check your drift monitor -- If AI-DRIFT.2 shows recent threshold breaches, be ready to explain what changed and how you responded.
Pull lifecycle chains -- If you used lifecycle chains (emergency overrides, champion-challenger testing), have the chain IDs ready. These show process maturity.
Print this document -- It prints as two pages. Page 1 (Side A) is the assessor's copy to keep. Page 2 (Side B) is your reference. Hand them page 1 at the start of the meeting -- it gives them independent verification before you present anything.
Have the SDK version ready -- The assessor may ask which SDK version minted the anchors. Check your package.json or pyproject.toml.

3. What the Assessor Will See

When the assessor opens the auditor portal, they will see:

Posture dashboard -- aggregate pass/fail rates across all procedures, filterable by framework
Verdict timeline -- chronological history of every evaluation, with PASS in green and FAIL in red
Individual anchor detail -- click any anchor to see the three evaluation factors (what was required, what was observed, threshold)
Lifecycle chains -- linked sequences showing how anchors relate (e.g., emergency override followed by remediation followed by re-assessment)
Export controls -- they can export the full ledger as JSON, the Compliance Passport as PDF-ready HTML, or OSCAL-formatted SAR

Tip: Make sure your ledger has recent entries. An assessor seeing a 90-day gap in witness activity will ask why. Continuous monitoring means continuous evidence.

4. Questions They Will Ask

Question	Where to Find the Answer
"How do I know this wasn't generated after the fact?"	The epoch timestamp in the anchor is locked at mint time. The fingerprint includes the timestamp. Changing it would break verification.
"Can you show me a failure?"	Filter the ledger by verdict=FAIL. Showing failures proves the system is honest, not just passing everything.
"What happens when a model drifts?"	AI-DRIFT.2 anchors show threshold breaches. Lifecycle chains show your response sequence (detect, investigate, remediate, re-assess).
"Is this independent from your dev team?"	The SDK witnesses at the point of execution. The fingerprint is computed client-side. The assessor verifies on public infrastructure. No human in the loop.
"How does this map to [specific control]?"	Open the Evidence Matrix (printable reference) or use the crosswalk search in your dashboard to look up any control in real time.
"What if you stop using this tool?"	Anchors are immutable once minted. Historical evidence remains verifiable indefinitely. The protocol is open; the anchors are not vendor-locked.

5. Hand Them This Sheet

At the end of the meeting, give the assessor this document (both sides). It gives them:

A public URL to verify evidence independently, on their own time
A framework mapping they can reference during their write-up
Links to deeper methodology guides when they need full detail
Confidence that the evidence format will be consistent across every future assessment

The goal: After this meeting, the assessor should be able to explain SWT3 anchors to their next client who does not have them yet. That is how a protocol becomes a standard.