SWT3 Protocol Specification

1. Abstract Informative

SWT3 (Sovereign Witness Traceability) is an open protocol for cryptographically anchoring evidence to immutable witness records while preserving data sovereignty. The "3" in SWT3 represents the three phases of the evidence lifecycle:

1. Provenance: Evidence collection and factor capture at the point of observation. Raw telemetry is decomposed into a structured Factor Matrix and cryptographically bound to a sub-second hardware epoch.
2. Verification: SHA-256 fingerprint computation binding factors to a self-describing, portable anchor token. Any party can independently re-derive the fingerprint from the original factors and confirm that evidence has not been altered, without network access, without database connectivity, and without trust in the issuing system.
3. Clearing: Controlled purging of raw evidence after anchoring, ensuring that sensitive telemetry does not persist beyond its operational usefulness. The cryptographic proof survives; the underlying data does not.

SWT3 does not prescribe how evidence is collected (Provenance). It defines how evidence is fingerprinted and anchored (Verification), and how raw evidence can be sovereignly purged while preserving cryptographic proof (Clearing). This separation allows any evidence collection tool to produce SWT3-compatible anchors, while any platform can consume and verify them without vendor lock-in.

2. Problem Statement Informative

Today, compliance evidence across every regulated industry relies on administrative trust: the assumption that whoever controls the database, the log file, or the cloud account has not altered the data. This model has three fundamental weaknesses:

• Unverifiable integrity. There is no way for an external party (auditor, assessor, regulator) to independently confirm that a piece of evidence has not been modified since it was collected. The only guarantee is organizational: "trust us, we did not change it."
• Data sovereignty conflict. Retaining raw evidence for auditability creates a persistent attack surface. Sensitive telemetry (command outputs, API responses, configuration files, prompts, model outputs) must be stored indefinitely to prove compliance, directly conflicting with data minimization requirements under GDPR, HIPAA, and national sovereignty mandates.
• No cross-platform portability. Every compliance tool, GRC platform, and audit framework uses proprietary evidence formats. There is no universal way to verify that a piece of evidence collected by System A is authentic when reviewed in System B.

SWT3 resolves all three. A cryptographic fingerprint proves integrity without requiring trust in the custodian. The Clearing Protocol destroys raw evidence while preserving the proof. And the self-describing anchor format makes every record portable and independently verifiable by any system with SHA-256 support.

3. Terminology Normative

4. Anchor Format Normative

An SWT3 anchor is a structured string token with the following format:

SWT3-{TIER}-{PROVIDER}-{UCT}-{PROCEDURE}-{VERDICT}-{EPOCH}-{FINGERPRINT}

4.1 Field Definitions

4.2 Parsing Rules

• Fields are separated by hyphens (-)
• The fingerprint is always the last segment
• The epoch is always the second-to-last segment
• Minimum 8 segments required for a valid anchor
• Protocol field MUST be SWT3

4.3 ABNF Grammar (RFC 5234)

swt3-anchor   = protocol "-" tier "-" provider "-" uct "-" procedure "-"
                verdict "-" epoch "-" fingerprint

protocol      = %s"SWT3"                         ; case-sensitive
tier          = %x45 / %x53 / %x48               ; "E" / "S" / "H"
provider      = 2*6ALPHA                          ; e.g., AWS, GCP, AZURE
uct           = 2*3ALPHA                          ; UCT Registry code
procedure     = 1*(ALPHA / DIGIT)                 ; normalized ID, no hyphens
verdict       = %s"PASS" / %s"FAIL"               ; normative verdicts
epoch         = 10DIGIT                           ; Unix seconds
fingerprint   = 12HEXDIG                          ; truncated SHA-256

4.4 Examples

SWT3-E-AWS-NET-SC76-PASS-1773316622-96b7d56c0245
SWT3-S-AWS-ACC-AC21-FAIL-1773400000-a3f7c2e91b04
SWT3-H-AZURE-CFG-CM61-INHERITED-1773500000-d2620f999950
SWT3-E-ON-PREM-CRY-SC28-PASS-1773600000-b1a9c3d4e5f6

5. Universal Control Taxonomy (UCT) Normative

UCT is a framework-agnostic classification system that maps every witnessed control into a domain. UCT codes are the bridge that allows SWT3 anchors to carry consistent meaning across compliance frameworks. A CRY anchor has the same semantic meaning whether it originated from a NIST SC-13 check, a PCI-DSS Requirement 4 assessment, or a HIPAA §164.312(a)(2)(iv) encryption review.

5.1 Core Codes

Core codes represent the fundamental security domains present in every major compliance framework. All SWT3 implementations MUST recognize core codes.

5.2 Extended Codes

Extended codes represent specialized domains for specific regulatory contexts or industry verticals. Implementations SHOULD recognize extended codes relevant to their compliance scope. Unrecognized extended codes MUST NOT cause verification failure.

5.3 Cross-Framework Portability

UCT codes map consistently across major compliance frameworks:

5.4 Registry Governance

• The UCT Registry is additive-only: codes are never removed or redefined once published
• New codes require demonstrated need across two or more compliance frameworks, clear semantic distinction from existing codes, and a 3-letter uppercase identifier
• Published codes remain valid for parsing and verification indefinitely
• Reserved codes (SWT, UCT, NIL, ERR, RAW, TBD) MUST NOT be assigned
• Submission process: Proposals for new UCT codes should be filed as issues on the SWT3 public issue tracker with the label uct-proposal. Each proposal must include: (a) the proposed 3-letter code, (b) the domain name, (c) mappings to at least two compliance frameworks, and (d) justification for why existing codes do not cover the domain

6. Fingerprint Algorithm Normative

The fingerprint is the cryptographic core of SWT3. It binds the evidence factors to the anchor in a deterministic, reproducible way.

6.1 Input Construction (Canonical Formula)

The fingerprint input is a colon-separated string with a WITNESS: domain separator prefix, followed by exactly six fields:

WITNESS:{tenant_id}:{procedure_id}:{factor_a}:{factor_b}:{factor_c}:{timestamp_ms}

6.2 Hash Computation

fingerprint = SHA-256(input_string)[0:12]

1. Encode the input string as UTF-8 bytes
2. Compute the SHA-256 digest
3. Convert to lowercase hexadecimal
4. Truncate to the first 12 characters

6.3 Determinism Guarantee

Given identical inputs, the fingerprint MUST always produce the identical output. This property enables cross-platform verification: an anchor minted in Python can be verified in TypeScript, Go, Rust, or any language with SHA-256 support.

6.4 Reference Computation

Input:       "WITNESS:DEMO_ENCLAVE:SC-7.6:4:3:-1:1773316622000"
SHA-256:     96b7d56c0245... (64 hex chars)
Fingerprint: 96b7d56c0245   (first 12 hex chars)

6.5 Why 12 Characters?

Twelve hexadecimal characters provide 48 bits of entropy (2⁴⁸ = ~281 trillion combinations). This provides collision resistance sufficient for compliance ledgers while keeping anchors human-readable and auditor-friendly. The full 64-character digest SHOULD be stored alongside the anchor for maximum verification fidelity.

7. Verification Normative

7.1 Single Anchor Verification

To verify an anchor, a verifier needs:

1. The SWT3 anchor token (to extract the claimed fingerprint)
2. The original factors: procedure_id, tenant_id, factor_a, factor_b, factor_c, timestamp_ms

Algorithm:
1. Extract claimed_fingerprint from anchor token (last segment)
2. Construct input string using the canonical formula (Section 6.1)
3. Compute SHA-256 of UTF-8 encoded input
4. Truncate to 12 hex characters
5. Compare: recomputed == claimed_fingerprint
6. Return VERIFIED if match, TAMPERED if mismatch

7.2 Verification Results

7.3 Enclave Integrity Verification

An enclave is a collection of anchors sharing a trust boundary (typically a single tenant or organization). Enclave integrity is computed as:

1. Collect all anchor fingerprints in the enclave
2. Sort fingerprints lexicographically
3. Join with colons: "fp1:fp2:fp3:..."
4. Compute SHA-256 of the joined string
5. The full 64-character hex digest is the Enclave Integrity Signature

Property: The same set of anchors in the same state always produces the same signature. Any addition, removal, or modification of an anchor changes the signature. This enables point-in-time integrity snapshots.

8. Clearing Protocol Normative

The Clearing Protocol is the third pillar of SWT3 and the mechanism by which data sovereignty is achieved without sacrificing integrity. After an anchor is minted and its fingerprint is sealed, the raw evidence used during Provenance SHOULD be purged from the witness system. Only the Factor Matrix, the timestamp, and the anchor token persist.

The cryptographic proof survives the data. The fingerprint remains independently verifiable even after the raw evidence that produced the factors has been destroyed. This is the core insight of SWT3: integrity does not require data retention.

8.1 Clearing Levels

8.2 Irreversibility

Clearing MUST be irreversible. Once raw evidence is purged, it MUST NOT be recoverable from the witness system. Implementations that offer a "soft delete" or "recoverable purge" MUST NOT claim SWT3 Clearing compliance.

9. OSCAL Integration Normative

SWT3 anchors are designed to embed naturally into NIST OSCAL (Open Security Controls Assessment Language) documents. This section defines the canonical mapping between SWT3 evidence and OSCAL Assessment Results.

9.1 Assessment Results Mapping

An SWT3 anchor maps to an OSCAL Assessment Result observation as follows:

{
  "results": [{
    "uuid": "<generated>",
    "title": "SWT3 Automated Assessment",
    "start": "<witnessed_at ISO-8601>",
    "observations": [{
      "uuid": "<generated>",
      "title": "<procedure_id> Evidence Observation",
      "description": "Automated evidence collection for <procedure_id>",
      "methods": ["TEST"],
      "relevant-evidence": [{
        "description": "SWT3 Witness Anchor: <swt_token>",
        "links": [{ "href": "#swt3-protocol", "rel": "evidence-source" }]
      }],
      "props": [
        { "name": "swt3-anchor", "value": "<full SWT3 token>" },
        { "name": "swt3-fingerprint", "value": "<12-char fingerprint>" },
        { "name": "swt3-factor-a", "value": "<factor_a>" },
        { "name": "swt3-factor-b", "value": "<factor_b>" },
        { "name": "swt3-factor-c", "value": "<factor_c>" },
        { "name": "swt3-timestamp-ms", "value": "<timestamp_ms>" }
      ]
    }],
    "findings": [{
      "uuid": "<generated>",
      "title": "<procedure_id> Finding",
      "target": {
        "type": "objective-id",
        "target-id": "<control-id>",
        "status": { "state": "<satisfied|not-satisfied>" }
      }
    }]
  }]
}

9.2 Verdict-to-OSCAL Status Mapping

9.3 Back-Matter Reference

SWT3-enabled OSCAL documents SHOULD include a back-matter resource identifying the protocol:

{
  "back-matter": {
    "resources": [{
      "uuid": "<generated>",
      "title": "SWT3 Protocol Specification v1.3",
      "description": "Sovereign Witness Traceability Protocol for evidence integrity",
      "props": [
        { "name": "type", "value": "protocol-specification" },
        { "name": "version", "value": "1.3.0" }
      ],
      "rlinks": [{
        "href": "https://tenova.io/specs/swt3-v1.3"
      }]
    }]
  }
}

10. AI Witnessing Profile Normative

This section defines the application of SWT3 to artificial intelligence and machine learning systems. The AI Witnessing Profile enables cryptographic attestation of model behavior, safety controls, and operational integrity throughout the AI lifecycle.

The AI Witnessing Profile addresses requirements from:

• NIST AI RMF (AI 100-1): MAP, MEASURE, MANAGE, GOVERN functions
• EU AI Act (Regulation 2024/1689): Articles 9, 12, 13, 14, 72
• ISO/IEC 42001: AI Management System controls

10.1 AI Procedure Registry

AI procedures use the AI UCT code and follow the naming convention AI-{DOMAIN}.{SEQUENCE}.

10.2 Clearing for AI Systems

AI systems present unique clearing considerations. Prompts may contain PII, trade secrets, medical records, or classified information.

10.3 Regulatory Coverage

10.4 Infrastructure-Layer Witnessing

SWT3 witnessing extends beyond application-layer SDKs to infrastructure-level integration. The protocol defines a two-layer architecture for inference serving platforms (e.g., NVIDIA Dynamo, vLLM, TGI):

Both layers produce identical SWT3 anchors and use the same fingerprint formula. Configuration is via a single DSN environment variable (SWT3_DSN=https://{api_key}@{endpoint}/{tenant_id}), enabling infrastructure teams to deploy witnessing through standard container orchestration without code changes.

Infrastructure-layer witnessing captures factors that application-layer SDKs cannot observe: GPU utilization, queue depth, batch scheduling decisions, and inference engine version. These factors flow through the same clearing protocol and appear as standard SWT3 anchors in the compliance ledger.

11. Conformance Levels Normative

SWT3 defines three conformance levels. Each level builds on the previous one.

Implementations MAY extend the metadata field with additional properties. Implementations MUST NOT modify the fingerprint algorithm or anchor format.

12. Security Considerations Informative

12.1 Truncation Risk

The 12-character (48-bit) fingerprint is not intended as a cryptographic signature. It is a verification shortcut. Systems requiring full cryptographic assurance SHOULD store and verify against the full 64-character SHA-256 digest.

12.2 Factor Confidentiality

Factor values (especially factor_a thresholds) may reveal security posture details. Implementations SHOULD apply access controls to factor data and leverage the Clearing Protocol at Level 1 or higher for sensitive environments.

12.3 Timestamp Manipulation

The timestamp_ms is a critical input to the fingerprint. An attacker who can control the timestamp can forge a valid fingerprint with different factors. Implementations MUST ensure timestamps are generated by trusted sources (system clock, NTP-synchronized) and not accepted from untrusted input.

12.4 Collision Resistance

At 48 bits, the birthday paradox threshold is approximately 2²⁴ (~16.7 million) anchors before a 50% collision probability. For most compliance ledgers (tens of thousands of anchors), this provides adequate uniqueness. Enclave integrity verification uses the full 64-character digest.

13. Test Vectors Normative

The following test vectors are canonical. Any conformant implementation MUST produce these exact fingerprints given these inputs. If your implementation produces a different fingerprint for any vector, it is not SWT3-conformant.

13.1 Verification Procedure

To validate your implementation against these vectors:

For each vector:
  1. Construct the input string exactly as shown (UTF-8)
  2. Compute SHA-256 of the input string
  3. Convert digest to lowercase hexadecimal
  4. Take the first 12 characters
  5. Compare against the expected fingerprint
  6. All 5 vectors MUST match for conformance

13.2 Edge Cases

The complete set of 13 fingerprint vectors, 2 signing vectors, and 5 hash vectors is available at github.com/tenova-labs/swt3-ai in test-vectors.json.

14. Getting Started Informative

Implement a working SWT3 fingerprint in any language with SHA-256 support. These examples use test vector #1 and should produce fingerprint 32241a3056cd.

14.1 Python

import hashlib

# Construct the canonical input string
input_str = "WITNESS:ACME_PROD:AI-INF.1:1:1:0:1774800000000"

# Compute SHA-256 and truncate to 12 hex chars
digest = hashlib.sha256(input_str.encode("utf-8")).hexdigest()
fingerprint = digest[:12]

print(fingerprint)  # 32241a3056cd

14.2 TypeScript / JavaScript

import { createHash } from "crypto";

// Construct the canonical input string
const input = "WITNESS:ACME_PROD:AI-INF.1:1:1:0:1774800000000";

// Compute SHA-256 and truncate to 12 hex chars
const digest = createHash("sha256").update(input, "utf8").digest("hex");
const fingerprint = digest.slice(0, 12);

console.log(fingerprint);  // 32241a3056cd

14.3 CLI (OpenSSL)

# One-liner: compute fingerprint from the canonical input
echo -n "WITNESS:ACME_PROD:AI-INF.1:1:1:0:1774800000000" \
  | openssl dgst -sha256 \
  | cut -d' ' -f2 \
  | cut -c1-12

# Output: 32241a3056cd

14.4 Using the SDK

# Python: full witness lifecycle in 4 lines
pip install swt3-ai
python -m swt3_ai.demo

# TypeScript: full witness lifecycle
npx swt3-demo

Both demos mint 3 SWT3 anchors locally with no API keys, no signup, and no network calls. They demonstrate the full Provenance, Verification, and Clearing lifecycle.

14.5 Verify Your Implementation

Paste any SWT3 anchor token into the public verifier to confirm your fingerprint matches: sovereign.tenova.io/verify. The verifier recomputes the fingerprint from the stored factors and returns CERTIFIED TRUTH or TAMPERED. No account required.

15. For Auditors Informative

This section explains how to use SWT3 anchors in assessment reports, conformity assessments, and audit findings. It is intended for C3PAOs, Notified Bodies, internal auditors, and assessors working with SWT3-enabled systems.

15.1 Verifying Evidence During Assessment

When reviewing an SWT3-enabled system, the assessor should:

1. Request the witness ledger export for the assessment period (JSON or OSCAL format)
2. Select a sample of anchors and verify each using the algorithm in Section 7.1. This can be done with the CLI, the SDK, or manually with any SHA-256 tool
3. Verify enclave integrity by computing the Enclave Integrity Signature (Section 7.3) and comparing against the system's claimed signature
4. Confirm the clearing level documented by the system and verify that raw evidence is not accessible at the claimed level

15.2 Citing SWT3 Evidence in Findings

The following template shows how to reference an SWT3 anchor in an assessment finding:

15.3 Bulk Verification (Full Assessment Period)

For assessments covering hundreds or thousands of anchors, use enclave-level verification rather than verifying each anchor individually:

# Request the JSON ledger export for the assessment period
# Then verify all anchors in one command:
swt3-verify --enclave --from 2026-01-01 --to 2026-06-30

# Output: Enclave Integrity Signature (64-char SHA-256)
# If even one anchor in the period has been altered, the signature changes.
# Compare against the system's claimed signature to confirm integrity.

This approach verifies the entire assessment period in a single operation. The Enclave Integrity Signature can be recorded in the assessment report as aggregate evidence of ledger integrity.

15.5 OSCAL Assessment Results

For assessments producing OSCAL-formatted results, use the mapping in Section 9 to embed SWT3 anchors directly into the Assessment Results document. Each anchor becomes an observation with props containing the factor values, and each verdict maps to an OSCAL finding status.

15.6 What Makes SWT3 Evidence Different

Traditional compliance evidence (screenshots, log exports, configuration dumps) requires the assessor to trust that the evidence has not been altered between collection and review. SWT3 evidence does not require this trust. The assessor independently recomputes the fingerprint from the factors and confirms the match. If the evidence has been altered, the fingerprint breaks. This is a mathematical guarantee, not an organizational one.

16. Reference Implementations Informative

The following open-source reference implementations are available:

All implementations share a common set of test vectors ensuring cross-language fingerprint parity. The same anchor minted in Python produces an identical fingerprint in Rust, C#, Ruby, and TypeScript. Community implementations in additional languages (Go, Java, Swift) are welcome; see the contribution guide for conformance requirements.

17. Citation Informative

When referencing this specification in academic papers, assessment reports, regulatory filings, or standards submissions, use one of the following formats:

TeNova. "SWT3 Protocol Specification v1.3: Sovereign Witness Traceability Protocol."
Proposed Standard. Tenable Nova LLC, April 2026.
https://tenova.io/specs/swt3-v1.3

@techreport{swt3-v1.3,
  title     = {SWT3 Protocol Specification v1.3:
               Sovereign Witness Traceability Protocol},
  author    = {{Tenable Nova LLC (DBA TeNova)}},
  year      = {2026},
  month     = {April},
  type      = {Proposed Standard},
  url       = {https://tenova.io/specs/swt3-v1.3},
  note      = {Apache 2.0. Patent pending.}
}

See Section 9.3 for the canonical OSCAL back-matter resource entry.

Related documents: Design Rationale (why each protocol decision was made) | MCP Compliance Binding (SWT3 + Model Context Protocol)

Appendix A: Version History