SWT3 Protocol

Verify any SWT3 anchor in 5 seconds.

No account. No software. Just SHA-256.

verification demo
Given -- anchor from client
SWT3-E-VULTR-AI-AIINF1-PASS-1774800000-2e16e2fe92dd
Inputs -- from witness payload JSON
Tenant IDENCLAVE_PROD ProcedureAI-INF.1 factor_a1  (model responded) factor_b1  (guardrails active) factor_c0  (no anomaly) Timestamp1774800000000 ms  (2026-04-15 12:00:00 UTC)
Step 1 -- construct input string
WITNESS:ENCLAVE_PROD:AI-INF.1:1:1:0:1774800000000
Step 2 -- compute SHA-256
$ echo -n "WITNESS:ENCLAVE_PROD:AI-INF.1:1:1:0:1774800000000" | sha256sum
2e16e2fe92dd... (64-character hex digest)
Step 3 -- compare first 12 characters
Computed: 2e16e2fe92dd   Claimed: 2e16e2fe92dd
VERIFIED

Your client's anchors will use their own tenant ID and procedure IDs. The verification process is identical -- only the input values change.

Critical Assessor Notice: Boundaries of Cryptographic Evidence

SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.

1. Why This Matters for Assessors

2. Anchor Anatomy

Every SWT3 Witness Anchor encodes its compliance context directly in the string. Each segment is color-coded below:

SWT3-E-VULTR-AI-AIINF1-PASS-1774800000-2e16e2fe92dd
Protocol (SWT3)
Tier (E=Enclave, S=SaaS, H=Hybrid)
Provider (hosting environment)
Namespace (AI, ACC, AUD, etc.)
Procedure (AI-INF.1)
Verdict (PASS or FAIL)
Epoch (2026-04-15 12:00 UTC)
Fingerprint (SHA-256, first 12 chars)

Both PASS and FAIL anchors are independently verifiable. Failures in the ledger demonstrate the system is honest, not optimistic. A deployment with zero FAILs should prompt additional scrutiny, not confidence.

What the Web Verifier Shows

When you paste an anchor into the public verifier, this is what you will see:

🔒 sovereign.tenova.io/verify
Anchor Token
SWT3-E-VULTR-AI-AIINF1-PASS-1774800000-2e16e2fe92dd
VERIFIED Fingerprint match confirmed. Computed: 2e16e2fe92dd | Claimed: 2e16e2fe92dd

If the anchor has been tampered with, the verifier shows a clear failure:

🔒 sovereign.tenova.io/verify
Anchor Token
SWT3-E-VULTR-AI-AIINF1-PASS-1774800000-000000000000
TAMPERED Fingerprint mismatch. Computed: 2e16e2fe92dd | Claimed: 000000000000

Why Tamper Detection Works

Changing any single input produces a completely different fingerprint. Here is a side-by-side comparison:

Original (Verified)

Input: WITNESS:ENCLAVE_PROD:AI-INF.1:1:1:0:1774800000000
Fingerprint: 2e16e2fe92dd

Modified (Tampered)

Input: WITNESS:ENCLAVE_PROD:AI-INF.1:0:1:0:1774800000000
Fingerprint: completely different

Changing factor_a from 1 to 0 (a single character) produces an entirely different SHA-256 digest. There is no way to modify evidence and preserve the original fingerprint.

3. Four Ways to Verify

Method 1 -- Recommended

Public Web Verifier

No tools required. Paste the anchor string and get an instant result. Works on any device with a browser.

sovereign.tenova.io/verify Paste the full anchor string. The verifier recomputes the fingerprint and confirms match/mismatch.
Method 2 -- Terminal (macOS/Linux)

Bash + sha256sum

Maximum independence. No network request required -- runs entirely on your machine.

echo -n "WITNESS:ENCLAVE_PROD:AI-INF.1:1:1:0:1774800000000" \ | sha256sum | cut -c1-12 # Output: 2e16e2fe92dd
Method 3 -- PowerShell (Windows)

PowerShell SHA-256

For assessors on locked-down Windows laptops. No software installation needed.

$s = "WITNESS:ENCLAVE_PROD:AI-INF.1:1:1:0:1774800000000" $bytes = [Text.Encoding]::UTF8.GetBytes($s) $hash = [BitConverter]::ToString( [Security.Cryptography.SHA256]::Create().ComputeHash($bytes) ).Replace("-","").ToLower().Substring(0,12) Write-Output $hash # Output: 2e16e2fe92dd
Method 4 -- Python

Python One-Liner

For assessors with Python available. Works with Python 3.6+.

python3 -c " import hashlib s = 'WITNESS:ENCLAVE_PROD:AI-INF.1:1:1:0:1774800000000' print(hashlib.sha256(s.encode()).hexdigest()[:12]) " # Output: 2e16e2fe92dd
All four methods produce the same result.

SHA-256 is a NIST-standardized algorithm (FIPS 180-4). Every implementation -- browser, terminal, PowerShell, Python, hardware module -- produces identical output for identical input. There is no proprietary component in SWT3 verification.

4. What Verification Proves (and What It Does Not)

Verification Proves

  • The anchor has not been tampered with since minting
  • The factors, tenant, procedure, and timestamp are authentic
  • The evaluation occurred at the claimed time
  • The verdict (PASS/FAIL) was deterministically computed from the stated inputs

Verification Does Not Prove

  • That the underlying AI system is compliant -- that is your determination
  • That factor values accurately represent operational reality
  • That the monitoring frequency is adequate for the assessment context
  • That all applicable controls have been evaluated

Verification confirms evidence integrity. Assessment determination -- whether the evidence is sufficient, appropriate, and relevant -- remains the assessor's professional responsibility.

5. Obtaining Verification Inputs

An anchor token contains the fingerprint but not the inputs needed to recompute it. To verify independently, request the witness payload JSON from the client. This is available via:

Factor Interpretation

Each procedure defines what factor_a, factor_b, and factor_c represent. These are not generic -- they carry procedure-specific meaning. The factor conventions below are defined by the SWT3 SDK. Verify with the client that their implementation follows these conventions -- ask for their factor mapping document if it differs from the defaults.

Procedurefactor_afactor_bfactor_c
AI-INF.1Model responded (1=yes)Guardrails active (1=yes)Anomaly detected (0=no)
AI-DRIFT.1Metric identifierObserved drift magnitudeConfigured threshold
AI-FAIR.1Protected attributeDisparity ratioAcceptable threshold
AI-GOV.1Policy versionCompliance status (1=compliant)Days since last review
AI-HITL.1Reviewer identity hashDecision (1=approved)Review duration (seconds)

For the full procedure catalog with factor definitions, see the UCT Registry (240 procedures, searchable).

6. How to Cite Verified Evidence in Your Report

When referencing SWT3 anchor verification in your assessment report, the following template provides a consistent citation format:

Sample citation

"The assessor independently verified SWT3 Witness Anchor [full token] using SHA-256 fingerprint recomputation (FIPS 180-4). The anchor confirms that procedure [procedure ID] was evaluated on [human-readable date] with verdict [PASS/FAIL]. Factor values: [factor_a description] = [value], [factor_b description] = [value], [factor_c description] = [value]. Verification method: [web verifier / terminal / PowerShell]. Result: fingerprint match confirmed -- evidence integrity verified."

Adapt the template to your report format and framework requirements. The key elements are: the full anchor token (for reproducibility), the verification method used, and the confirmation that the fingerprint matched.

Methodology Boundary

This guide documents evidence format and verification procedures. It does not prescribe assessment methodology. Sample sizes, sufficiency determinations, and assessment conclusions remain the assessor's professional responsibility under their applicable accreditation and regulatory requirements.

7. Next Steps