# SWT3 Protocol Specification v1.0

## Sovereign Witness Traceability Protocol

**Status:** Proposed Standard
**Version:** 2.0.0
**Date:** 2026-08-30
**Authors:** Tenable Nova LLC (DBA TeNova)
**License:** Apache 2.0

---

### Notation Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)
and [RFC 8174](https://www.ietf.org/rfc/rfc8174.txt).

---

## 1. Abstract

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, establishing an immutable record of what was
   observed, when, and under what conditions.

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 (command outputs, configuration files, API responses, log entries)
   does not persist beyond its operational usefulness. The cryptographic proof survives;
   the underlying data does not. This achieves 100% integrity verification and 100%
   data sovereignty simultaneously  --  not as a tradeoff, but as complementary guarantees.

SWT3 enables any party  --  auditor, assessor, or automated system  --  to independently
verify that a piece of evidence has not been altered since the moment it was
witnessed, even after the raw source data has been cleared.

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. Terminology

| Term | Definition |
|------|-----------|
| **Witness** | The act of observing a state and recording its factors at the point of origin |
| **Factor** | A measurable input to a determination (e.g., open port count, patch age, sensor reading) |
| **Factor Matrix** | The structured triple (factor_a, factor_b, factor_c) captured during Provenance |
| **Anchor** | A self-describing cryptographic receipt binding factors to a verdict at a specific point in time |
| **Fingerprint** | The truncated SHA-256 digest that seals the anchor |
| **Verdict** | The determination outcome: PASS, FAIL, INHERITED, LAPSED, or UNKNOWN |
| **Enclave** | A trust boundary within which anchors share a common verification chain |
| **Clearing** | The controlled purging of raw evidence after anchoring, preserving the cryptographic proof while destroying the source telemetry to maintain data sovereignty |
| **Administrative Trust** | The legacy trust model where data integrity depends on trusting the custodian (database admin, cloud provider, agency) rather than independent mathematical verification |

## 3. Anchor Format

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

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

### 3.1 Field Definitions

| Field | Width | Values | Description |
|-------|-------|--------|-------------|
| Protocol | 4 | `SWT3` | Fixed protocol identifier |
| Tier | 1 | `E`, `S`, `H` | Deployment tier: Enclave, SaaS, Hybrid |
| Provider | 2-6 | `VULTR`, `AWS`, `AZURE`, `GCP`, `HYBRID`, `ON-PREM` | Infrastructure provider |
| UCT | 2-3 | See Section 3.2 | Universal Control Taxonomy category (UCT Registry v1.0) |
| Procedure | 2-6 | e.g. `SC76`, `AC21` | Procedure identifier (alphanumeric, no hyphens) |
| Verdict | 4-9 | `PASS`, `FAIL`, `INHERITED`, `LAPSED`, `UNKNOWN` | Compliance determination |
| Epoch | 10 | Unix timestamp | Seconds since Unix epoch at witness time |
| Fingerprint | 12 | Hex string | First 12 characters of SHA-256 digest |

### 3.2 UCT Registry (v1.0)

The Universal Control Taxonomy (UCT) is a framework-agnostic classification
system that categorizes every witnessed control into a domain. UCT codes are
the bridge that allows SWT3 anchors to be meaningful across compliance
frameworks  --  a `CRY` anchor carries 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.

The UCT Registry is **additive-only**: codes are never removed or redefined
once published. New codes may be added in future registry versions. Anchors
minted under any registry version remain valid under all subsequent versions.

#### 3.2.1 Core Codes

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

| Code | Domain | Description |
|------|--------|-------------|
| `ACC` | Access Control | Authorization, privileges, least privilege, account management  --  who can get in and what they can do |
| `AUD` | Audit & Accountability | Logging, log retention, audit review, event correlation  --  proving who did what |
| `CFG` | Configuration Management | Baselines, hardening, change control, inventory  --  how systems are set |
| `CRY` | Cryptography | Encryption at rest, encryption in transit, key management, certificate lifecycle |
| `IDN` | Identity & Authentication | Authentication mechanisms, MFA, credential management  --  proving who you are |
| `INT` | System Integrity | Patching, file integrity monitoring, malware defense, code signing  --  tamper evidence |
| `NET` | Network Security | Firewalls, segmentation, boundary protection, traffic filtering  --  network boundaries |
| `BCP` | Business Continuity | Backup, disaster recovery, contingency planning, availability  --  surviving failure |
| `GOV` | Governance & Policy | Security policy, planning, system security plans, authorization  --  the policy layer |
| `IRP` | Incident Response | Detection, response, recovery, lessons learned  --  handling the breach |
| `PHY` | Physical Security | Facility access, media protection, environmental controls  --  the physical layer |

#### 3.2.2 Extended Codes

Extended codes represent specialized domains that apply in specific regulatory
contexts or industry verticals. Implementations SHOULD recognize extended codes
relevant to their compliance scope. Unrecognized extended codes MUST NOT cause
verification failure  --  the anchor remains valid; only the domain classification
is opaque to that implementation.

| Code | Domain | Description |
|------|--------|-------------|
| `ACQ` | Supply Chain & Acquisition | Vendor risk, third-party assessment, supply chain integrity |
| `AI`  | AI / ML Governance | Model integrity, algorithmic fairness, AI risk management (NIST AI RMF) |
| `CHG` | Change Management | Change approval, maintenance windows, controlled modification |
| `DEV` | Secure Development | SDLC, code review, application security testing |
| `EVI` | Evidence & Artifacts | Ingested proof artifacts, external evidence anchoring |
| `HRS` | Personnel Security | Screening, termination, role-based access tied to employment status |
| `MON` | Continuous Monitoring | Ongoing surveillance, posture dashboards, trend analysis (CA-7) |
| `OT`  | Operational Technology | ICS/SCADA, industrial control systems, NERC CIP |
| `PRI` | Privacy | PII protection, consent management, data subject rights (GDPR, HIPAA Privacy Rule) |
| `RSK` | Risk Management | Risk assessments, POA&Ms, risk acceptance, vulnerability prioritization |
| `TRN` | Training & Awareness | Security training, phishing exercises, role-based training requirements |
| `VUL` | Vulnerability Management | Scanning, patching cadence, CISA KEV, remediation tracking |

#### 3.2.3 NIST 800-53 Family Mapping

The following table defines the canonical mapping from NIST 800-53 control
families to UCT codes. This mapping is normative for NIST-derived frameworks
(FedRAMP, CMMC, 800-171, DoD RMF) and informative for all others.

| NIST Family | UCT Code | Notes |
|-------------|----------|-------|
| AC (Access Control) | `ACC` | |
| AU (Audit & Accountability) | `AUD` | |
| CM (Configuration Management) | `CFG` | |
| IA (Identification & Authentication) | `IDN` | |
| SC (System & Communications) | `NET` | Default for SC family |
| SC-8, SC-8.x (Transmission Confidentiality) | `CRY` | Encryption in transit |
| SC-13 (Cryptographic Protection) | `CRY` | Cryptographic mechanisms |
| SC-28, SC-28.x (Protection of Information at Rest) | `CRY` | Encryption at rest |
| SI (System & Information Integrity) | `INT` | Default for SI family |
| SI-2 (Flaw Remediation) | `VUL` | Patching and remediation |
| SI-5 (Security Alerts & Advisories) | `VUL` | Advisory monitoring |
| AT (Awareness & Training) | `TRN` | |
| CP (Contingency Planning) | `BCP` | |
| IR (Incident Response) | `IRP` | |
| MA (Maintenance) | `CHG` | |
| MP (Media Protection) | `PHY` | |
| PE (Physical & Environmental) | `PHY` | |
| PL (Planning) | `GOV` | |
| PS (Personnel Security) | `HRS` | |
| RA (Risk Assessment) | `RSK` | |
| SA (System & Services Acquisition) | `ACQ` | |
| CA (Assessment, Authorization & Monitoring) | `MON` | CA-7 specifically maps to MON |

#### 3.2.4 Cross-Framework Reference

UCT codes map consistently across major compliance frameworks:

| UCT | NIST 800-53 | SOC 2 (TSC) | HIPAA | PCI-DSS 4.0 | ISO 27001:2022 |
|-----|-------------|-------------|-------|-------------|----------------|
| `ACC` | AC | CC6.1, CC6.3 | §164.312(a)(1) | Req 7, 8 | A.5.15, A.8.3 |
| `AUD` | AU | CC7.2 | §164.312(b) | Req 10 | A.8.15 |
| `CFG` | CM | CC8.1 | §164.310(d)(2)(iii) | Req 2 | A.8.9 |
| `CRY` | SC-8, SC-13, SC-28 | CC6.1 (enc.) | §164.312(a)(2)(iv), §164.312(e)(2)(ii) | Req 3, 4 | A.8.24 |
| `IDN` | IA | CC6.1 (auth.) | §164.312(d) | Req 8 | A.8.5 |
| `INT` | SI | CC7.1 | §164.312(c)(1) | Req 5, 6, 11 | A.8.7 |
| `NET` | SC (network) | CC6.6 | §164.312(e)(1) | Req 1 | A.8.20, A.8.21 |
| `BCP` | CP | A1.2 | §164.308(a)(7) | Req 12.10.1 | A.5.29, A.5.30 |
| `GOV` | PL | CC1.1-CC1.5 | §164.308(a)(1) | Req 12 | A.5.1 |
| `IRP` | IR | CC7.3, CC7.4 | §164.308(a)(6) | Req 12.10 | A.5.24-A.5.28 |
| `PHY` | PE, MP | CC6.4 | §164.310(a), §164.310(d) | Req 9 | A.7.1-A.7.14 |

#### 3.2.5 Registry Governance

- **Maintainer:** Tenable Nova LLC (DBA TeNova)
- **Versioning:** UCT Registry follows semantic versioning independent of the SWT3 spec version
- **Additions:** New codes require (a) demonstrated need across two or more compliance frameworks, (b) clear semantic distinction from existing codes, and (c) a 3-letter uppercase alphabetic identifier
- **Immutability:** Published codes are never removed, renamed, or redefined
- **Deprecation:** A code may be marked DEPRECATED with a recommended successor, but MUST remain valid for parsing and verification indefinitely
- **Reserved codes:** `SWT`, `UCT`, `NIL`, `ERR`, `RAW`, `TBD` are reserved and MUST NOT be assigned
- **Legacy code  --  `POL`:** Pre-v1.0 implementations used `POL` (Policy) as a catch-all for governance, personnel, incident response, training, physical security, risk, and acquisition domains. Anchors minted with `POL` remain valid and MUST be accepted by all implementations. New anchors SHOULD use the specific code from the registry. Implementations MAY reclassify historical `POL` anchors using the procedure ID prefix and the NIST Family Mapping (Section 3.2.3).

### 3.3 Examples

```
SWT3-E-VULTR-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
SWT3-S-AWS-IRP-IR41-PASS-1773700000-7f8e9d0c1b2a
SWT3-E-VULTR-VUL-SI21-FAIL-1773800000-4d5e6f7a8b9c
```

### 3.4 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`

### 3.5 ABNF Grammar (RFC 5234)

```abnf
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., VULTR, AWS, GCP
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
```

Implementations MUST accept the above grammar for well-formed anchors.
Implementations SHOULD additionally accept `INHERITED`, `LAPSED`, and
`UNKNOWN` as informative verdict values in contexts where these verdicts
originate from platform-level adjudication (not protocol-level witnessing).

## 4. Fingerprint Algorithm

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

### 4.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}
```

| Field | Type | Description |
|-------|------|-------------|
| `WITNESS` | literal | Domain separator prefix (REQUIRED since v1.1.0) |
| `tenant_id` | string | The organization/tenant identifier |
| `procedure_id` | string | The procedure identifier (e.g., `SC-7.6`)  --  original format, NOT normalized |
| `factor_a` | integer | Baseline/threshold factor (string representation of decimal integer) |
| `factor_b` | integer | Measured/observed factor |
| `factor_c` | integer | Delta factor (typically `factor_b - factor_a`) |
| `timestamp_ms` | integer | Millisecond-precision Unix timestamp at witness time |

**IMPORTANT:** The `procedure_id` in the fingerprint input retains its original
format (e.g., `SC-7.6`), while the anchor token uses the normalized form (e.g.,
`SC76`). This distinction is intentional  --  the anchor is human-readable; the
fingerprint is cryptographic.

#### 4.1.1 Legacy Formula (Pre-v1.1.0)

Anchors minted before v1.1.0 used the formula without the `WITNESS:` prefix
and with reversed tenant/procedure order:

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

Verifiers SHOULD attempt the canonical formula first, then fall back to the
legacy formula if verification fails. This supports backward compatibility
with pre-v1.1.0 anchors without ambiguity (the `WITNESS:` prefix is
unambiguous).

### 4.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**

### 4.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.

### 4.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)
```

### 4.5 Why 12 Characters?

Twelve hexadecimal characters provide 48 bits of entropy (2^48 = ~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.

## 5. Witness Requirements

A valid SWT3 witness MUST satisfy all of the following:

### 5.1 Factor Integrity

All three factors (`factor_a`, `factor_b`, `factor_c`) MUST be recorded at the
moment of observation. Factors MUST be integer values. Implementations SHOULD
use signed 32-bit integers minimum.

### 5.2 Temporal Binding

The `timestamp_ms` MUST be captured at the moment of witnessing, not at a later
processing stage. Millisecond precision is REQUIRED. The `epoch` field in the
anchor token uses second precision (floor of `timestamp_ms / 1000`).

### 5.3 Clearing Protocol (Phase 3)

The Clearing phase 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  --  command outputs, file contents, API responses, log
entries, sensor readings, and any other source telemetry  --  SHOULD be purged
from the witness system. Only the **Factor Matrix** (factor_a, factor_b,
factor_c), the **timestamp**, and the **anchor token** should 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**.

#### 5.3.1 Clearing Levels

Implementations SHOULD support one or more of the following clearing levels:

| Level | Name | Behavior |
|-------|------|----------|
| 0 | **RETAIN** | Raw evidence retained alongside factors. Maximum forensic capability, maximum attack surface. |
| 1 | **FACTOR-ONLY** | Raw evidence purged after factor extraction. Factors and anchor persist. RECOMMENDED default. |
| 2 | **ANCHOR-ONLY** | Factors purged after fingerprint computation. Only the anchor token persists. Verification requires the verifier to have obtained factors through a separate channel. |
| 3 | **SOVEREIGN** | All local evidence destroyed after anchor is transmitted to the verifier. The minting system retains nothing. Maximum data sovereignty. |

The clearing level SHOULD be configurable per enclave or per sensitivity
classification. Implementations MUST document their clearing level in their
security posture.

#### 5.3.2 Clearing and Verification Compatibility

Clearing levels 0 and 1 support full self-contained verification (the verifier
has both the anchor and the factors). Clearing levels 2 and 3 require
out-of-band factor exchange  --  the factors must be transmitted to the verifier
before or at the time of clearing. This is appropriate for classified or
air-gapped environments where the minting system cannot retain any data.

#### 5.3.3 Irreversibility

Clearing MUST be irreversible. Once raw evidence is purged, it MUST NOT be
recoverable from the witness system. The purpose of clearing is to ensure
that sensitive telemetry cannot be exfiltrated, subpoenaed, or reverse-engineered
from the witness ledger. Implementations that offer a "soft delete" or
"recoverable purge" MUST NOT claim SWT3 Clearing compliance.

### 5.4 Non-Repudiation

Once an anchor is minted, the factors used to compute its fingerprint MUST be
immutable. Any system that stores anchors MUST prevent modification of:
- `factor_a`, `factor_b`, `factor_c`
- `fingerprint_timestamp_ms`
- `swt_token`

Modification of any of these fields will cause verification to return `TAMPERED`.

## 6. Verification

### 6.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: "{procedure_id}:{tenant_id}:{factor_a}:{factor_b}:{factor_c}:{timestamp_ms}"
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
```

### 6.2 Verification Results

| Status | Meaning |
|--------|---------|
| `CERTIFIED TRUTH` | Fingerprints match. Evidence integrity confirmed. |
| `TAMPERED` | Fingerprints do not match. Evidence or factors have been modified. |
| `INVALID TOKEN` | Anchor does not conform to SWT3 format. |
| `LEGACY ANCHOR` | Anchor predates timestamp-based fingerprinting. Cannot verify. |

### 6.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.

## 7. OSCAL Integration

SWT3 anchors are designed to embed naturally into NIST OSCAL (Open Security
Controls Assessment Language) documents.

### 7.1 Assessment Results Mapping

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

```json
{
  "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"],
      "subjects": [{
        "subject-uuid": "<control-uuid>",
        "type": "component"
      }],
      "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>"
        }
      },
      "related-observations": [{
        "observation-uuid": "<observation-uuid-above>"
      }]
    }]
  }]
}
```

### 7.2 Back-Matter Reference

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

```json
{
  "back-matter": {
    "resources": [{
      "uuid": "<generated>",
      "title": "SWT3 Protocol Specification v1.0",
      "description": "Sovereign Witness Traceability Protocol for evidence integrity",
      "props": [
        { "name": "type", "value": "protocol-specification" },
        { "name": "version", "value": "1.0.0" }
      ],
      "rlinks": [{
        "href": "https://swt3.ai/spec/"
      }]
    }]
  }
}
```

### 7.3 Verdict-to-OSCAL Status Mapping

| SWT3 Verdict | OSCAL Finding Status |
|-------------|---------------------|
| `PASS` | `satisfied` |
| `FAIL` | `not-satisfied` |
| `INHERITED` | `satisfied` (with prop `inheritance-source`) |
| `LAPSED` | `not-satisfied` (with prop `lapse-reason`) |
| `UNKNOWN` | `not-satisfied` (with prop `assessment-pending: true`) |

## 8. Transport

### 8.1 JSON Evidence Factor

The canonical transport format for SWT3 evidence is a JSON object:

```json
{
  "swt3_version": "1.0",
  "anchor": "SWT3-E-VULTR-NET-SC76-PASS-1773316622-96b7d56c0245",
  "factors": {
    "procedure_id": "SC-7.6",
    "tenant_id": "DEMO_ENCLAVE",
    "factor_a": 4,
    "factor_b": 3,
    "factor_c": -1,
    "timestamp_ms": 1773316622000
  },
  "verdict": "PASS",
  "witnessed_at": "2026-03-18T12:00:00Z",
  "metadata": {
    "source": "example-collector-v1.0",
    "check_type": "command",
    "control_family": "SC"
  }
}
```

### 8.2 Batch Transport

Multiple evidence factors MAY be transported as a JSON array:

```json
{
  "swt3_version": "1.0",
  "enclave_id": "DEMO_ENCLAVE",
  "anchors": [
    { "anchor": "SWT3-...", "factors": {...} },
    { "anchor": "SWT3-...", "factors": {...} }
  ],
  "enclave_signature": "<64-char SHA-256 of sorted fingerprints>"
}
```

### 8.3 Payload Signing and Server-Side Validation

SDKs MAY sign witness payloads using HMAC-SHA256 to enable server-side
authenticity verification. This provides a second layer of security beyond
API key authentication: the API key authenticates transport, while the
signing key authenticates payload origin.

**Signature Formula (LOCKED):**
```
message = agent_id ? "{fingerprint}:{agent_id}" : "{fingerprint}"
signature = HMAC-SHA256(signing_key, message)  // 64-char lowercase hex
```

Cross-language parity is required. All SDK implementations MUST produce
identical signatures for the same inputs. Test vectors are provided in
`test-vectors.json` (signing_vectors).

**Server-Side Validation:**

Compliant servers MUST implement progressive enforcement:

1. If the payload carries no `payload_signature`, accept it (status: "unsigned").
2. If the payload carries a `payload_signature` but the tenant has no
   registered signing keys, accept it (status: "unverified").
3. If the payload carries a `payload_signature` and the tenant has registered
   signing keys, re-compute the HMAC for each active key. If any key produces
   a matching signature, accept it (status: "verified"). If no key matches,
   reject the payload with HTTP 422 (status: "failed").

Signature comparison MUST use constant-time comparison to prevent timing
side-channel attacks.

Signing keys MUST be stored encrypted at rest. Implementations SHOULD use
envelope encryption (e.g., AES-256-GCM with a server-side master key).

The `payload_signature` field survives all clearing levels (0-3). It is
classified as operational metadata, not evidence content.

### 8.3.1 Key Identification Fields

SDKs MAY include optional key identification metadata alongside the signature
to enable efficient server-side validation and rotation auditing:

- `signing_key_id` (string, optional) -- Identifies which registered key
  produced the signature. When present, the server SHOULD look up that
  specific key for O(1) validation rather than iterating all active keys.
  If the key_id is not found or inactive, the server MUST fall back to
  iterating all active keys before rejecting.

- `signing_key_version` (integer, optional) -- Monotonically increasing
  version counter for the same logical key. Set by the operator during key
  rotation. Enables audit queries like "which key generation signed this
  anchor?" without decrypting key material.

These fields are NOT part of the HMAC message. The signing formula remains
locked. They are routing and auditing metadata only.

### 8.3.2 Signing Security Tiers

Implementations SHOULD classify signing key posture into one of four tiers.
This classification is informational -- servers MUST NOT reject payloads
based on tier alone, but SHOULD record the tier in observations for audit.

| Tier | Name | Key Storage | Rotation | Use Case |
|------|------|-------------|----------|----------|
| 0 | Development | Plaintext env var or config file | Manual, ad-hoc | Local development, CI test suites |
| 1 | Standard | Encrypted at rest (AES-256-GCM or equivalent) | Manual with key_version tracking | Production SaaS deployments |
| 2 | Enterprise | KMS-managed (AWS KMS, GCP CMEK, Azure Key Vault) | Automatic, policy-driven (30-90 day cycle) | Regulated enterprise, SOC 2 |
| 3 | Sovereign | HSM-backed (FIPS 140-2 Level 3+) or OIDC ephemeral | Per-session or per-deployment | FedRAMP, defense, air-gapped enclaves |

**Tier Requirements:**

- **Tier 0**: No encryption requirement. Key MAY be stored in plaintext.
  Suitable only for development and testing.

- **Tier 1**: Key MUST be encrypted at rest using authenticated encryption
  (AES-256-GCM or equivalent). Key material MUST NOT appear in logs,
  environment variable dumps, or error messages. The Axiom reference
  implementation uses AES-256-GCM with a server-side master key.

- **Tier 2**: Key MUST be managed by a dedicated key management service.
  Rotation MUST be automated with configurable policy (recommended: 90 days
  maximum). Key material MUST never leave the KMS boundary in plaintext
  except for the signing operation itself.

- **Tier 3**: Key MUST be backed by a hardware security module (HSM)
  certified to FIPS 140-2 Level 3 or higher, OR generated ephemerally via
  OIDC identity binding (Sigstore/Fulcio model) where the key exists only
  for the duration of the signing session. Air-gapped deployments MUST use
  HSM-backed keys; cloud-native deployments MAY use OIDC ephemeral signing.

**Compliance Mapping:**

- NIST 800-53 SC-12 (Cryptographic Key Establishment): Tier 1+ satisfies.
- CMMC L2 SC.L2-3.13.10 (Key Management): Tier 1+ satisfies.
- FedRAMP Moderate SC-12: Tier 2+ recommended, Tier 3 for High.
- EU AI Act Art. 15 (Cybersecurity): Tier 1+ for standard risk, Tier 2+
  for high-risk AI systems.

**Server Reporting:**

When a server can determine the signing tier (e.g., from key metadata or
tenant configuration), it SHOULD include `signing_tier` in the observations
JSONB alongside `signature_status`.

## 9. AI Witnessing Profile

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 is designed to satisfy 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
- **NIST 800-53 AI family**: Controls prefixed AI- in the Axiom taxonomy

### 9.1 AI Procedure Registry

AI procedures use the `AI` UCT code and follow the naming convention
`AI-{DOMAIN}.{SEQUENCE}`, where DOMAIN identifies the witnessing category.

| Procedure ID | Domain | Description | Regulatory Basis |
|-------------|--------|-------------|------------------|
| `AI-INF.1` | Inference Provenance | Witness that a specific model produced a specific output | EU AI Act Art. 12 (Record-keeping), NIST AI RMF MEASURE 2.6 |
| `AI-INF.2` | Inference Latency | Witness response time against SLA thresholds | NIST AI RMF MANAGE 2.2 |
| `AI-INF.3` | Inference Volume | Witness request throughput for capacity governance | NIST AI RMF MANAGE 2.4 |
| `AI-MDL.1` | Model Integrity | Witness that deployed weights match the approved registry hash | EU AI Act Art. 9(4)(b), NIST AI RMF MANAGE 1.3 |
| `AI-MDL.2` | Model Version | Witness which model version served production traffic | EU AI Act Art. 12(2)(a) |
| `AI-MDL.3` | Model Drift | Witness accuracy/performance degradation against baseline | NIST AI RMF MEASURE 1.1 |
| `AI-GRD.1` | Guardrail Enforcement | Witness that required safety filters were active | EU AI Act Art. 9(4)(a), NIST AI RMF GOVERN 1.5 |
| `AI-GRD.2` | Content Safety | Witness content filter activation and block rate | EU AI Act Art. 9(8) |
| `AI-GRD.3` | PII Redaction | Witness PII detection and scrubbing before/after inference | GDPR Art. 25, NIST AI RMF GOVERN 1.7 |
| `AI-FAIR.1` | Bias Measurement | Witness demographic parity or equalized odds metrics | EU AI Act Art. 10(2)(f), NIST AI RMF MEASURE 2.11 |
| `AI-FAIR.2` | Fairness Threshold | Witness pass/fail against defined fairness bounds | NIST AI RMF MAP 2.3 |
| `AI-DATA.1` | Training Data Provenance | Witness dataset hash at training time | EU AI Act Art. 10, NIST AI RMF MAP 4.1 |
| `AI-DATA.2` | Training Data License | Witness that training data provenance includes license verification | EU AI Act Art. 53(1)(d) |
| `AI-DATA.3` | Training Data Statistics | Witness summary statistics of training dataset (row count, feature count, class balance) | EU AI Act Art. 10(3), NIST AI RMF MAP 4.1 |
| `AI-DATA.4` | Training Data PII Lifecycle | Witness pseudonymization, access restriction, or deletion of personal data used in training | EU AI Act Art. 10(5), GDPR Art. 25 |
| `AI-HITL.1` | Human Review | Witness that a human reviewed an AI-generated decision | EU AI Act Art. 14, NIST AI RMF GOVERN 1.4 |
| `AI-HITL.2` | Override Decision | Witness that a human overrode the AI recommendation | EU AI Act Art. 14(4)(a) |
| `AI-EXPL.1` | Explainability | Witness that an explanation was generated alongside output | EU AI Act Art. 13, NIST AI RMF GOVERN 1.5 |
| `AI-EXPL.2` | Confidence Score | Witness model confidence against minimum threshold | NIST AI RMF MEASURE 2.9 |
| `AI-TOOL.1` | Tool Call | Witness an AI agent's tool/function call with outcome | EU AI Act Art. 14(4), NIST AI RMF MANAGE 4.2 |
| `AI-ID.1` | Agent Identity | Witness that an AI agent's cryptographic identity was asserted | EU AI Act Art. 50(2), NIST AI RMF GOVERN 1.2 |
| `AI-ACC.1` | Access Control | Witness an AI agent's access to external resources with scope | EU AI Act Art. 9(4)(c), NIST AI RMF MANAGE 2.3 |
| `AI-REV.1` | Anchor Revocation | Witness the revocation of a previously-issued anchor with reason | EU AI Act Art. 12(3), GDPR Art. 17 |
| `AI-SEC.1` | Adversarial Detection | Witness that adversarial threat detection was performed on an inference (prompt injection, data poisoning, model extraction) | EU AI Act Art. 15(4), NIST AI RMF MANAGE 3.2 |
| `AI-SEC.2` | Input Validation | Witness that input was validated and sanitized before inference | EU AI Act Art. 15(3), NIST AI RMF MEASURE 2.7 |
| `AI-RAG.1` | Context Retrieval Provenance | Witness what context chunks were retrieved and from which corpus in a RAG pipeline | EU AI Act Art. 12(2)(a), NIST AI RMF MAP 3.5 |
| `AI-RAG.2` | Context Relevance | Witness similarity scoring and relevance thresholds for retrieved context chunks | EU AI Act Art. 10(2), NIST AI RMF MEASURE 2.6 |
| `AI-MDL.5` | Weight File Integrity | Witness SHA-256 hash of actual model weight files for tamper detection | EU AI Act Art. 15(4), NIST AI RMF MANAGE 1.3 |
| `AI-MDL.6` | Adapter Stack Attestation | Witness which LoRA/QLoRA/PEFT adapters are active on a base model | EU AI Act Art. 12(2)(b), NIST AI RMF MAP 2.3 |
| `AI-MDL.7` | Quantization Attestation | Witness the quantization method applied to model weights | EU AI Act Art. 15(3), NIST AI RMF MEASURE 2.5 |
| `AI-SKILL.1` | Skill Manifest Attestation | Witness which skills, tools, and plugins are loaded in an AI agent | EU AI Act Art. 12(2)(b), NIST AI RMF GOVERN 1.7 |
| `AI-SKILL.2` | Memory Context Binding | Witness what persistent memory sources influenced an AI decision | EU AI Act Art. 12(2)(a), NIST AI RMF MAP 3.5 |
| `AI-SKILL.3` | Reward Model Binding | Witness which RLHF/DPO reward model scored or filtered the output | EU AI Act Art. 9(4)(a), NIST AI RMF MEASURE 2.6 |
| `AI-CHAIN.1` | Multi-Agent Chain Witnessing | Witness a handoff between agents in a multi-agent chain with cycle tracking | EU AI Act Art. 12(2)(a), NIST AI RMF MANAGE 4.1 |
| `AI-VIO.1` | Violation Reporting | Witness a policy violation detected during or after inference | EU AI Act Art. 9(4)(a), NIST AI RMF MANAGE 3.2 |
| `AI-CHR.1` | Agent Charter Attestation | Witness the charter or system prompt hash governing an agent's behavior | EU AI Act Art. 13, NIST AI RMF GOVERN 1.2 |
| `AI-MDL.8` | Model Registry Check | Witness that a model was verified against an approved registry before deployment | EU AI Act Art. 51, NIST AI RMF MANAGE 1.3 |
| `AI-HITL.3` | Reviewer Identity Binding | Witness the identity of the natural person who performed a human review or override | EU AI Act Art. 12(3)(d), Art. 14(5) |
| `AI-SAFE.1` | Safe State Attestation | Witness that a stop or interrupt mechanism exists and the system reached safe state | EU AI Act Art. 14(4)(e), NIST AI RMF MANAGE 4.1 |
| `AI-HW.1` | Hardware Attestation | Witness accelerator hardware inventory (GPU count, topology, interconnect) at service startup | EU AI Act Art. 15(4), NIST AI RMF MANAGE 1.3 |
| `AI-HW.3` | TPM Platform Attestation | Witness TPM 2.0 PCR register state proving host firmware integrity and hardware root of trust | NIST 800-53 SC-12, EU AI Act Art. 15(4) |
| `AI-TRUST.1` | Trust Verification | Witness mutual compliance trust verification between AI agents before interaction | EU AI Act Art. 9(4)(c), NIST AI RMF GOVERN 1.2 |
| `AI-TRUST.2` | Trust Handshake | Witness the detailed handshake result (checks performed, checks passed) of a trust verification | EU AI Act Art. 12(2)(a), NIST AI RMF MANAGE 4.1 |
| `AI-FAIR.3` | Bias Audit | Witness periodic bias audit results against protected categories | EU AI Act Art. 10(2)(f), NIST AI RMF MEASURE 2.11 |
| `AI-CHAIN.2` | Chain Trust Credential | Witness chain-of-trust credential verification between agents in a pipeline | EU AI Act Art. 9(4)(c), NIST AI RMF MANAGE 4.1 |
| `AI-ENV.1` | Runtime Environment | Witness the runtime environment fingerprint (OS, language version, package hashes) at startup | EU AI Act Art. 15(4), NIST AI RMF MANAGE 1.3 |
| `AI-ENV.2` | Dependency Manifest | Witness the dependency tree and lock file hash for supply chain integrity | EU AI Act Art. 15(3), NIST AI RMF MANAGE 1.3 |
| `AI-MARK.1` | Content Provenance | Witness AI-generated content marking with method and content type | EU AI Act Art. 50(2), NIST AI RMF GOVERN 1.7 |
| `AI-BASE.1` | Agent Behavioral Baseline | Witness agent behavioral baseline establishment, monitoring, or drift detection | NIST AI RMF MEASURE 2.6, EU AI Act Art. 9(4)(a) |
| `AI-LIC.1` | License Provenance | Witness license composition of models, adapters, and data with SPDX identification | EU AI Act Art. 53(1)(d), NIST AI RMF GOVERN 1.7 |
| `AI-SBOM.1` | AI Bill of Materials | Witness AI system component inventory with G7 cluster coverage and format | G7/CISA SBOM-AI, EU AI Act Art. 11, EO 14028 |
| `AI-REDTEAM.1` | Adversarial Test Campaign | Witness red team campaign results with coverage category and pass rate | EO 14110, EU AI Act Art. 9(7), NIST AI 100-2 |
| `AI-CONSENT.1` | Data Subject Consent | Witness data subject consent documentation with legal basis and withdrawal status | GDPR Art. 6/7, EU AI Act Art. 10 |
| `AI-MULTI.1` | Multi-Agent Delegation | Witness inter-agent permission delegation with depth, scope, and time bounds | EU AI Act Art. 9, NIST AI RMF GOVERN 1.3 |
| `AI-DRIFT.1` | Model Drift Detection | Witness statistical model drift including data, concept, and prediction drift | EU AI Act Art. 9(2)(b), NIST AI RMF MEASURE 2.6 |
| `AI-AUDIT.1` | Audit Log Integrity | Witness verification of audit trail integrity and traceability | EU AI Act Art. 12, GDPR Art. 30 |
| `AI-INCIDENT.1` | Incident Reporting | Witness serious incident reporting to authorities | EU AI Act Art. 62, NIST AI RMF MANAGE 3.2 |
| `AI-PERF.1` | Performance Metrics | Witness model performance benchmark results with accuracy levels | EU AI Act Art. 15(1), NIST AI RMF MEASURE 2.5 |
| `AI-ROBUST.1` | Robustness Testing | Witness resilience against errors, faults, and inconsistencies | EU AI Act Art. 15(3), NIST AI RMF MEASURE 2.6 |
| `AI-CYBER.1` | Cybersecurity Attestation | Witness cybersecurity assessment results against framework controls | EU AI Act Art. 15(4), NIST CSF |
| `AI-TRANS.1` | Transparency Disclosure | Witness AI usage disclosures to deployers, users, and data subjects | EU AI Act Art. 13, GDPR Art. 13/14 |
| `AI-WATERMARK.1` | Watermark Verification | Witness verification that AI content marking survived downstream processing | EU AI Act Art. 50(2), GPAI Code of Practice |
| `AI-DPIA.1` | Data Protection Impact Assessment | Witness DPIA completion for high-risk AI processing | GDPR Art. 35, EU AI Act Art. 27 |
| `AI-AUTO.1` | Automated Decision Notification | Witness notification of automated decisions with legal effects | GDPR Art. 22, EU AI Act Art. 14 |
| `AI-DUALUSE.1` | Dual-Use Model Classification | Witness classification and reporting of dual-use foundation models | EO 14110 Sec 4(a), NIST AI RMF GOVERN 1.1 |
| `AI-SUPPLY.1` | Supply Chain Risk | Witness third-party AI supply chain risk assessment | NIST AI RMF MEASURE 3.1, G7/CISA SBOM-AI, EO 14028 |
| `AI-PMM.1` | Post-Market Monitoring | Witness execution of post-market monitoring plans | EU AI Act Art. 72, NIST AI RMF MANAGE 4.1 |
| `AI-METAGOV.1` | Governance Self-Witnessing | Witness governance infrastructure configuration changes | NIST AI RMF GOVERN 1.1, EU AI Act Art. 9 |
| `AI-DEL.1` | Delegation Witnessing | Witness scope-bounded authority delegation between agents | EU AI Act Art. 14(4), NIST AI RMF GOVERN 1.3 |
| `AI-CAP.1` | Capability Attestation | Witness runtime capability manifest with drift detection | EU AI Act Art. 12(2)(b), NIST AI RMF MAP 1.5 |
| `AI-COST.1` | Resource Consumption | Witness resource consumption (tokens, API calls, compute) as compliance evidence | NIST AI RMF MANAGE 2.4, EU AI Act Art. 9 |
| `AI-AUTO.3` | Autonomy Transition | Witness promotion or demotion of agent autonomy levels | EU AI Act Art. 14, NIST AI RMF GOVERN 1.4 |
| `AI-MOB.1` | Offline SIM Attestation | Witness offline attestation buffer with SIM integrity verification on reconnection | EU AI Act Art. 12, NIST AI RMF MANAGE 1.3 |
| `AI-EMRG.1` | Emergency Override | Witness human-initiated override lifecycle with continuous checkpoints | EU AI Act Art. 14(4)(e), NIST AI RMF MANAGE 4.1 |
| `AI-DRIFT.2` | Consequence-Mapped Drift | Witness statistical drift mapped to consequence severity categories | EU AI Act Art. 9(2)(b), NIST AI RMF MEASURE 2.6 |
| `AI-ASSESS.1` | Champion-Challenger Assessment | Witness parallel-run model comparison with divergence tracking | OCC SR 26-2, NIST AI RMF MEASURE 2.5 |
| `AI-SAMPLE.1` | Probabilistic Sampling | Witness sampling decisions for high-volume attestation pipelines | EU AI Act Art. 12, NIST AI RMF MANAGE 2.2 |

#### 9.1.1 Non-Human Identity (NHI) Namespace

NHI procedures witness credential lifecycle events for non-human identities (service accounts, API keys, machine credentials) as an independent, out-of-band audit trail. SWT3 does NOT issue, validate, or enforce credentials. It records reported lifecycle events.

| Procedure ID | Domain | Description | Regulatory Basis |
|-------------|--------|-------------|------------------|
| `NHI-SCOPE.1` | Credential Scope | Witness reported credential scope with canonical scope hashing and TTL | NIST IA-4, EU AI Act Art. 9(4)(c), NIS-2 Art. 21(2)(i) |
| `NHI-CYCLE.1` | Credential Lifecycle | Witness credential lifecycle events (issued, activated, suspended, expired, revoked) | NIST IA-5, EU AI Act Art. 12(1), NIS-2 Art. 21(2)(i) |
| `NHI-PRIV.1` | Privilege Change | Witness credential privilege changes with scope delta tracking | NIST AC-6, EU AI Act Art. 9(4)(c), NIS-2 Art. 21(2)(d) |
| `NHI-ROTATE.1` | Credential Rotation | Witness credential rotation with old/new hash linking and reason tracking | NIST IA-5(1), EU AI Act Art. 9(9), NIS-2 Art. 21(2)(i) |
| `NHI-AGENT.1` | Credential Delegation | Witness agent-to-agent credential delegation with depth tracking | NIST AC-2(7), EU AI Act Art. 14(4), OWASP Agentic MCP-07 |
| `NHI-REVOKE.1` | Credential Revocation | Witness credential revocation with cascade flag for delegation tree propagation | NIST IA-5(2), EU AI Act Art. 16(i), NIS-2 Art. 21(2)(i) |

#### 9.1.2 Hardware Bill of Materials (HBOM) Namespace

HBOM procedures witness hardware component inventory, lifecycle, and environmental metrics. SWT3 records reported values; it does NOT measure temperature, power, or water consumption.

| Procedure ID | Domain | Description | Regulatory Basis |
|-------------|--------|-------------|------------------|
| `HBOM-INV.1` | Hardware Inventory | Witness hardware component inventory with manifest hashing and baseline delta | EU CRA Art. 10(9), NIST CM-8 |
| `HBOM-LIFE.1` | Component Lifecycle | Witness component lifecycle events (installed through recycled) | EU Battery Reg Art. 77, NIST SA-22 |
| `HBOM-THERM.1` | Thermal Profile | Witness reported thermal measurements with threshold alerting | EU Battery Reg Art. 14, NIST PE-14 |
| `HBOM-WATER.1` | Water Consumption | Witness reported water consumption with WUE ratio and source classification | CSRD ESRS-E3, EU EED Art. 12 |
| `HBOM-PUE.1` | Power Usage Effectiveness | Witness reported PUE with facility and IT load measurements | EU EED Art. 12, ISO 30134-2 |
| `HBOM-SUPPLY.1` | Supply Chain Provenance | Witness hardware supply chain provenance with country of origin hashing | EU Battery Reg Art. 39, EU CRA Art. 10(9), EU Conflict Minerals 2017/821 |

#### 9.1.3 Digital Product Passport (DPP) Namespace

DPP procedures witness battery and product lifecycle data for EU Battery Regulation and ESPR Digital Product Passport compliance.

| Procedure ID | Domain | Description | Regulatory Basis |
|-------------|--------|-------------|------------------|
| `DPP-SOH.1` | Battery State of Health | Witness reported battery SoH percentage, cycle count, and remaining capacity | EU Battery Reg Art. 14(1) |
| `DPP-CHRG.1` | Charge/Discharge Cycle | Witness charge and discharge cycle events with energy transfer and peak temperature | EU Battery Reg Art. 14(1), IEC 62619 |
| `DPP-DEGRAD.1` | Degradation Event | Witness battery degradation events with cause classification and SoH impact | EU Battery Reg Art. 14(1) |
| `DPP-EOL.1` | End-of-Life Handoff | Witness end-of-life disposition with handler identification and final SoH | EU Battery Reg Art. 59, EU WEEE 2012/19 |

#### 9.1.4 Automated Demand Response (ADR) Namespace

ADR procedures witness energy grid demand response event lifecycles. SWT3 does NOT control grid operations, measure power, or dispatch curtailment. It records reported values from participants.

| Procedure ID | Domain | Description | Regulatory Basis |
|-------------|--------|-------------|------------------|
| `ADR-EVENT.1` | DR Event Lifecycle | Witness demand response event phases (signal received through restoration) | FERC Order 2222, EU CEP Art. 17 |
| `ADR-BASE.1` | Baseline Consumption | Witness reported baseline power consumption with measurement methodology | FERC Order 2222, EU CEP Art. 17 |
| `ADR-CURT.1` | Curtailment Verification | Witness actual curtailment against committed values with compliance ratio | FERC Order 2222, EU CEP Art. 17 |
| `ADR-SETTLE.1` | Settlement Data | Witness settlement quantities and prices with event count | FERC Order 2222, EU CEP Art. 17 |
| `ADR-CARBON.1` | Carbon Credit / REC | Witness carbon credit and REC issuance with registry identification | EU CBAM 2023/956, EU RED III, SEC Climate S-K Item 1504 |
| `ADR-GRID.1` | Grid Signal Correlation | Witness grid signal type, response latency, and operator identification | FERC Order 2222, NERC BAL-001 |

### 9.2 Factor Matrix Semantics for AI

The SWT3 Factor Matrix (factor_a, factor_b, factor_c) carries domain-specific
meaning for each AI procedure. The following table defines the canonical
factor semantics. Implementations MUST use these semantics for interoperability.

| Procedure | factor_a (baseline/threshold) | factor_b (observed) | factor_c (delta) |
|-----------|------|------|------|
| `AI-INF.1` | Model weight hash (first 10 digits as integer) | Input hash (first 10 digits as integer) | Output hash (first 10 digits as integer) |
| `AI-INF.2` | Latency SLA threshold (ms) | Actual latency (ms) | `factor_b - factor_a` (negative = within SLA) |
| `AI-INF.3` | Capacity threshold (req/min) | Actual throughput (req/min) | `factor_b - factor_a` |
| `AI-MDL.1` | Approved hash (first 10 digits as integer) | Running hash (first 10 digits as integer) | Match flag (1 = match, 0 = mismatch) |
| `AI-MDL.2` | Expected version (integer encoding) | Deployed version (integer encoding) | Match flag (1 = match, 0 = mismatch) |
| `AI-MDL.3` | Baseline accuracy (× 1000, e.g., 950 = 95.0%) | Current accuracy (× 1000) | `factor_b - factor_a` (negative = degradation) |
| `AI-GRD.1` | Required guardrail count | Active guardrail count | `factor_b - factor_a` (negative = missing) |
| `AI-GRD.2` | Block rate threshold (× 1000) | Actual block rate (× 1000) | `factor_b - factor_a` |
| `AI-GRD.3` | PII fields requiring redaction | PII fields successfully redacted | `factor_b - factor_a` (0 = compliant) |
| `AI-FAIR.1` | Parity threshold (× 1000, e.g., 800 = 80.0%) | Measured parity ratio (× 1000) | `factor_b - factor_a` (negative = violation) |
| `AI-FAIR.2` | Fairness bound (× 1000) | Measured fairness score (× 1000) | `factor_b - factor_a` |
| `AI-DATA.1` | Approved dataset hash (first 10 digits) | Actual training hash (first 10 digits) | Match flag (1 = match, 0 = unauthorized) |
| `AI-DATA.2` | Required license flags (bitmask) | Verified license flags (bitmask) | `factor_b AND factor_a` XOR `factor_a` (0 = compliant) |
| `AI-DATA.3` | Row count (total samples) | Feature count (dimensions) | Class balance ratio (x1000, e.g., 850 = 85% balance) |
| `AI-DATA.4` | Records affected (count) | 1 if event completed, 0 if partial/failed | Event type code (0=unspecified, 1=pseudonymization, 2=anonymization, 3=access_restriction, 4=deletion, 5=encryption) |
| `AI-HITL.1` | Review required flag (1 = yes) | Review completed flag (1 = yes) | `factor_b - factor_a` (0 = compliant) |
| `AI-HITL.2` | AI recommendation hash (first 10 digits) | Final decision hash (first 10 digits) | Override flag (1 = overridden, 0 = accepted) |
| `AI-EXPL.1` | Explanation required flag (1 = yes) | Explanation generated flag (1 = yes) | `factor_b - factor_a` (0 = compliant) |
| `AI-EXPL.2` | Minimum confidence threshold (× 1000) | Actual confidence score (× 1000) | `factor_b - factor_a` (negative = below threshold) |
| `AI-TOOL.1` | 1 (tool was called) | Latency (ms) | 1 if succeeded, 0 if exception |
| `AI-ID.1` | 1 (identity asserted) | 1 (identity verified) | 0 (reserved) |
| `AI-ACC.1` | 1 (access attempted) | 1 if within scope, 0 if out of scope | 1 if granted, 0 if denied |
| `AI-REV.1` | 1 (revocation event) | 1 (target declared) | Reason code (0=unspecified, 1=model_recall, 2=policy_violation, 3=data_contamination, 4=consent_withdrawal, 5=regulatory_order, 6=error_correction) |
| `AI-SEC.1` | Detection threshold (threat score x 1000) | Observed threat score (x 1000) | Threat type code (0=none, 1=prompt_injection, 2=data_poisoning, 3=model_extraction, 4=jailbreak, 5=adversarial_input) |
| `AI-SEC.2` | 1 (validation required) | 1 if validation passed, 0 if rejected | 0 if clean, 1 if sanitized, 2 if blocked |
| `AI-RAG.1` | Chunk count (number of chunks retrieved) | 1 if corpus_id provided, 0 if anonymous | 0 (reserved) |
| `AI-RAG.2` | Similarity threshold (x 1000, e.g., 750 = 0.75) | Average similarity (x 1000) | Chunks below threshold count |
| `AI-MDL.5` | 1 (integrity check required) | 1 if weight hash matches expected, 0 if mismatch | 0 (reserved) |
| `AI-MDL.6` | Adapter count (number loaded) | 1 if all adapter hashes verified, 0 if any unverified | 0 (reserved) |
| `AI-MDL.7` | 1 (attestation required) | 1 (attested) | Quantization code (0=FP32, 1=FP16, 2=BF16, 3=INT8, 4=INT4, 5=GPTQ, 6=AWQ, 7=GGUF) |
| `AI-SKILL.1` | Skill count (number loaded) | 1 if manifest hash matches expected, 0 if mismatch | 0 (reserved) |
| `AI-SKILL.2` | Memory source count | 1 if all sources identified, 0 if any anonymous | 0 (reserved) |
| `AI-SKILL.3` | 1 (reward model required) | 1 if reward model identified, 0 if unknown | 0 (reserved) |
| `AI-CHAIN.1` | Chain depth (position in sequence, 1-based) | 1 if cycle_id bound, 0 if standalone | 1 if handoff accepted, 0 if rejected |
| `AI-VIO.1` | Violation severity (1=low, 2=medium, 3=high, 4=critical) | 1 if auto-detected, 0 if manually reported | Policy code (0=unspecified, 1=content, 2=access, 3=data, 4=safety, 5=regulatory) |
| `AI-CHR.1` | 1 (charter required) | 1 if charter hash matches expected, 0 if mismatch | 0 (reserved) |
| `AI-MDL.8` | 1 (registry check required) | 1 if model found in approved registry, 0 if not found | 0 if approved, 1 if pending review, 2 if denied |
| `AI-HITL.3` | Reviewer count required (e.g., 2 for four-eyes) | Reviewer count actual | Identity binding method (0=none, 1=session, 2=cryptographic) |
| `AI-SAFE.1` | 1 (stop mechanism required) | 1 if mechanism exists and tested, 0 if absent | 1 if safe state confirmed after last invocation, 0 if not confirmed |
| `AI-HW.1` | GPU count (number of accelerators detected) | 1 if all healthy and topology matches expected, 0 if mismatch | Topology code (0=single, 1=multi-gpu/DGX, 2=NVL36/NVL72/multi-node, 3=unknown) |
| `AI-HW.3` | PCR registers read (count) | 1 if all non-zero (healthy), 0 if uninitialized/tampered | 0 (reserved) |
| `AI-TRUST.1` | 1 (trust verification performed) | 1 if trust granted, 0 if denied | Trust level (0=denied, 1=basic, 2=verified, 3=attested, 4=sovereign) |
| `AI-TRUST.2` | Checks performed (count) | Checks passed (count) | 1 if trust granted, 0 if denied |
| `AI-FAIR.3` | Audit frequency required (days) | Days since last audit | Categories audited count |
| `AI-CHAIN.2` | 1 (credential verification required) | 1 if credential valid, 0 if invalid/expired | Trust level of presenting agent (0-4) |
| `AI-ENV.1` | Expected environment hash (first 10 digits) | Actual environment hash (first 10 digits) | Match flag (1 = match, 0 = drift) |
| `AI-ENV.2` | Expected dependency count | Actual dependency count | Lock file hash match (1 = match, 0 = mismatch) |
| `AI-MARK.1` | Content type code (0=text, 1=image, 2=audio, 3=video, 4=code, 5=multimodal, 6=synthetic_data) | Marking method (0=metadata, 1=watermark, 2=c2pa, 3=header, 4=visible) | Content hash (first 10 digits as integer) |
| `AI-BASE.1` | Mode (0=establishing, 1=monitoring, 2=drift_detected, 3=baseline_reset) | Metric count (number of tracked metrics) | Drift score (x1000, e.g., 150 = 0.150) |
| `AI-LIC.1` | Components checked (count) | All compliant (1=yes, 0=violation) | License type code (0=permissive, 1=copyleft, 2=proprietary, 3=dual, 4=openmdw, 5=unknown) |
| `AI-SBOM.1` | Total components (count) | G7 clusters documented (0-7) | Format code (0=cyclonedx, 1=spdx, 2=custom, 3=unknown) |
| `AI-REDTEAM.1` | Tests executed (count) | Tests passed (count) | Coverage category code (0-10) |
| `AI-CONSENT.1` | Subjects covered (count) | Legal basis code (0-5) | Withdrawal available (1=yes, 0=no) |
| `AI-MULTI.1` | Delegation depth (hops) | Permissions granted (count) | Time bound minutes (0=unbounded) |
| `AI-DRIFT.1` | Metrics evaluated (count) | Drifted count | Drift type code (0-5) |
| `AI-AUDIT.1` | Entries checked (count) | Integrity verified (1=yes, 0=no) | Log format code (0-3) |
| `AI-INCIDENT.1` | Severity code (1-4) | Authority notified (1=yes, 0=no) | Incident type code (0-5) |
| `AI-PERF.1` | Metrics evaluated (count) | Metrics passing (count) | Benchmark type code (0-5) |
| `AI-ROBUST.1` | Perturbations tested (count) | Perturbations survived (count) | Perturbation type code (0-5) |
| `AI-CYBER.1` | Controls assessed (count) | Controls compliant (count) | Framework code (0-4) |
| `AI-TRANS.1` | Disclosures made (count) | Disclosure type code (0-4) | Recipient type code (0-3) |
| `AI-WATERMARK.1` | Items checked (count) | Watermarks detected (count) | Detection method code (0-4) |
| `AI-DPIA.1` | Risks identified (count) | Risks mitigated (count) | Processing type code (0-4) |
| `AI-AUTO.1` | Decisions made (count) | Human reviewed (count) | Decision type code (0-5) |
| `AI-DUALUSE.1` | Classification code (0-2) | Reporting status code (0-3) | Days since classification |
| `AI-SUPPLY.1` | Suppliers assessed (count) | Suppliers compliant (count) | Risk level code (0-3) |
| `AI-PMM.1` | Monitoring checks run (count) | Anomalies detected (count) | Monitoring type code (0-4) |
| `AI-EMRG.1` | Override trigger type (1=emergency_stop, 2=operator_command, 3=escalation, 4=external) | Authorization level (1=operator, 2=supervisor, 3=site_manager, 4=emergency_responder) | Fallback state (1=safe_state, 2=legacy_controller, 3=manual_mode, 4=degraded, 5=shutdown) |
| `AI-DRIFT.2` | Consequence severity (1=safety, 2=environmental, 3=financial, 4=operational, 5=reputational) | Drift metric value (x1000) | Threshold value (x1000) |
| `AI-ASSESS.1` | Divergence metric value (x1000) | Challenger model hash (first 10 digits) | Assessment decision (0=pending, 1=promote, 2=reject, 3=extend) |
| `AI-SAMPLE.1` | Total events in window | Sampled events in window | Sampling rate (x1000) |
| `NHI-SCOPE.1` | Credential ID hash (SHA-256[:16] as integer) | Scope hash (SHA-256[:16] of canonical scope as integer) | TTL in seconds (0=non-expiring) |
| `NHI-CYCLE.1` | Event type (1=issued, 2=activated, 3=suspended, 4=expired, 5=revoked) | Credential ID hash (SHA-256[:16] as integer) | Issuer hash (SHA-256[:16] as integer) |
| `NHI-PRIV.1` | Credential ID hash (SHA-256[:16] as integer) | Previous scope hash (SHA-256[:16] as integer, 0 if new) | New scope hash (SHA-256[:16] as integer) |
| `NHI-ROTATE.1` | Old credential hash (SHA-256[:16] as integer) | New credential hash (SHA-256[:16] as integer) | Rotation reason (1=scheduled, 2=compromise, 3=policy, 4=manual) |
| `NHI-AGENT.1` | Delegator credential hash (SHA-256[:16] as integer) | Delegatee credential hash (SHA-256[:16] as integer) | Delegation depth (1=direct, 2+=chained) |
| `NHI-REVOKE.1` | Revoked credential hash (SHA-256[:16] as integer) | Reason code (0-6, same as AI-REV.1) | Cascade flag (1=cascade to delegated, 0=single) |
| `HBOM-INV.1` | Component count (total in inventory) | Manifest hash (SHA-256[:16] as integer) | Delta from baseline (added/removed count) |
| `HBOM-LIFE.1` | Event type (1=installed, 2=commissioned, 3=maintained, 4=degraded, 5=decommissioned, 6=recycled) | Component hash (SHA-256[:16] as integer) | Age in days since installation |
| `HBOM-THERM.1` | Ambient temperature (Celsius) | Component temperature (Celsius) | Threshold exceeded (1=alarm, 0=normal) |
| `HBOM-WATER.1` | Liters consumed | WUE ratio (x1000) | Source type (1=municipal, 2=recycled, 3=rainwater, 4=groundwell, 5=mixed) |
| `HBOM-PUE.1` | Total facility power (kW) | IT load power (kW) | PUE ratio (x1000, e.g., 1200=PUE 1.2) |
| `HBOM-SUPPLY.1` | Supplier hash (SHA-256[:16] as integer) | Provenance verified (1=yes, 0=no) | Country of origin hash (SHA-256[:16] as integer) |
| `DPP-SOH.1` | SoH percentage (x100, e.g., 9230=92.30%) | Cycle count | Remaining capacity kWh (x100) |
| `DPP-CHRG.1` | Event type (1=charge_start, 2=charge_complete, 3=discharge_start, 4=discharge_complete) | Energy kWh (x100) | Peak temperature (Celsius) |
| `DPP-DEGRAD.1` | Degradation type (1=calendar_aging, 2=thermal_stress, 3=overcharge, 4=deep_discharge, 5=mechanical, 6=unknown) | SoH drop (percentage points x100) | Ambient temperature (Celsius) |
| `DPP-EOL.1` | Disposition (1=recycling, 2=repurpose, 3=refurbishment, 4=landfill, 5=hazmat) | Handler hash (SHA-256[:16] as integer) | Final SoH (x100) |
| `ADR-EVENT.1` | Event phase (1=signal_received, 2=curtailment_start, 3=curtailment_end, 4=restoration) | Committed curtailment (kW) | Signal source hash (SHA-256[:16] as integer) |
| `ADR-BASE.1` | Baseline consumption (kW) | Measurement method (1=metered_10day_avg, 2=regression, 3=real_time_meter, 4=deemed_savings) | Confidence level (x1000) |
| `ADR-CURT.1` | Actual reduction (kW) | Committed curtailment (kW) | Compliance ratio (x1000, 1000=100%) |
| `ADR-SETTLE.1` | Settlement quantity kWh (x100) | Price USD/MWh (x100) | Event count in settlement period |
| `ADR-CARBON.1` | Credit type (1=REC, 2=carbon_offset, 3=EAC, 4=guarantee_of_origin) | Quantity MWh (x100) or tonnes CO2e (x100) | Registry hash (SHA-256[:16] as integer) |
| `ADR-GRID.1` | Signal type (1=emergency, 2=economic, 3=capacity, 4=frequency_regulation, 5=voltage_support) | Response latency (ms) | Grid operator hash (SHA-256[:16] as integer) |

### 9.3 Clearing Protocol for AI Systems

AI systems present unique Clearing considerations due to the sensitivity of
inference data (prompts may contain PII, trade secrets, medical records, or
classified information). The Clearing Protocol (Section 5.3) applies to AI
systems with these additional guidance:

#### 9.3.1 Recommended Clearing Levels by AI Context

| Context | Recommended Level | Rationale |
|---------|-------------------|-----------|
| Internal analytics | Level 0 (RETAIN) | Full forensic capability for model debugging |
| B2B SaaS inference | Level 1 (FACTOR-ONLY) | Factors retained, prompts/responses cleared |
| Healthcare / PII | Level 2 (ANCHOR-ONLY) | Factors may reveal PHI; only anchor persists |
| Classified / defense | Level 3 (SOVEREIGN) | Nothing persists on the minting system |

#### 9.3.2 Inference Clearing Sequence

For AI-INF procedures, the clearing sequence is:

```
1. Capture prompt and response (Provenance)
2. Compute input_hash = SHA-256(prompt)[0:20] as integer
3. Compute output_hash = SHA-256(response)[0:20] as integer
4. Mint SWT3 anchor with factor matrix (Verification)
5. Clear prompt and response from memory/storage (Clearing)
```

After step 5, the implementation retains only the anchor and factor matrix.
The original prompt and response are irrecoverable from the factors  --  only
their hashes are preserved, and SHA-256 is pre-image resistant. This satisfies
GDPR Article 17 (Right to Erasure) while preserving Article 12 (Transparency)
of the EU AI Act: you can prove the inference happened and verify its integrity
without being able to reconstruct the data.

### 9.4 AI Enclave Verification

AI systems SHOULD support enclave-level verification analogous to Section 6.3.
An AI Enclave encompasses all anchors produced by a single AI system (model +
infrastructure + guardrails) within a trust boundary.

The AI Enclave Integrity Signature covers:
- All AI-INF anchors (inference provenance)
- All AI-MDL anchors (model integrity)
- All AI-GRD anchors (guardrail enforcement)
- All AI-FAIR anchors (fairness measurements)
- All AI-HITL anchors (human oversight)
- All AI-EXPL anchors (explainability)

This enables a single verification command to attest the complete operational
integrity of an AI system over any time window:

```bash
swt3-verify --enclave --filter "AI-*" --from 2026-01-01 --to 2026-03-31
```

The resulting Enclave Integrity Signature can be included in:
- EU AI Act conformity assessment documentation
- NIST AI RMF assessment reports
- ISO 42001 management review evidence
- SOC 2 + AI supplementary criteria reports

### 9.5 AI Witness Transport Extension

The JSON transport format (Section 8.1) is extended for AI procedures with
an `ai_context` field in the metadata object:

```json
{
  "swt3_version": "1.0",
  "anchor": "SWT3-S-AWS-AI-AIINF1-PASS-1773900000-a4c7e2f91b03",
  "factors": {
    "procedure_id": "AI-INF.1",
    "tenant_id": "ACME_CORP",
    "factor_a": 2847593016,
    "factor_b": 1938274650,
    "factor_c": 7462019385,
    "timestamp_ms": 1773900000000
  },
  "verdict": "PASS",
  "witnessed_at": "2026-04-15T14:30:00Z",
  "metadata": {
    "source": "swt3-ai-sdk-v1.0",
    "check_type": "inference",
    "ai_context": {
      "model_id": "gpt-4o-2025-04-16",
      "model_provider": "openai",
      "guardrails_active": ["content_safety", "pii_redaction", "fairness_monitor"],
      "clearing_level": 1,
      "risk_tier": "high",
      "regulatory_scope": ["eu-ai-act", "nist-ai-rmf"]
    }
  }
}
```

The `ai_context` metadata is OPTIONAL and is not included in the fingerprint
computation. It provides operational context for ledger queries, dashboards,
and reporting. Implementations at Clearing Level 2+ SHOULD omit `ai_context`
or restrict it to non-sensitive fields.

### 9.6 Regulatory Mapping

#### 9.6.1 EU AI Act Coverage

| EU AI Act Article | Requirement | SWT3 AI Procedure |
|-------------------|-------------|-------------------|
| Art. 9(4)(a) | Risk management measures operational | AI-GRD.1, AI-GRD.2 |
| Art. 9(4)(b) | Appropriate testing and validation | AI-MDL.1, AI-MDL.3 |
| Art. 9(8) | Residual risk mitigation | AI-GRD.2, AI-FAIR.1 |
| Art. 10 | Data governance | AI-DATA.1, AI-DATA.2, AI-DATA.3 |
| Art. 10(5) | Personal data safeguards in training | AI-DATA.4 |
| Art. 10(2)(f) | Bias examination | AI-FAIR.1, AI-FAIR.2 |
| Art. 12(1) | Automatic logging capability | AI-INF.1 (all inferences anchored) |
| Art. 12(2)(a) | Log identification of input/output | AI-INF.1 (input/output hashes), AI-CHAIN.1 (multi-agent tracing) |
| Art. 12(3)(d) | Identification of natural persons verifying results | AI-HITL.3 |
| Art. 13 | Transparency and information | AI-EXPL.1, AI-EXPL.2, AI-CHR.1 |
| Art. 14 | Human oversight | AI-HITL.1, AI-HITL.2, AI-HITL.3 |
| Art. 14(4)(a) | Ability to override | AI-HITL.2 |
| Art. 14(4)(e) | Stop button and safe state | AI-SAFE.1 |
| Art. 14(5) | Four-eyes verification (biometrics) | AI-HITL.3 |
| Art. 51 | Registration in EU database | AI-MDL.8 |
| Art. 53(1)(d) | Training data transparency (GPAI) | AI-DATA.2 |
| Art. 72 | Post-market monitoring | AI-MDL.3, AI-FAIR.1 (continuous) |

#### 9.6.2 NIST AI RMF Coverage

| AI RMF Function | Category | SWT3 AI Procedure |
|-----------------|----------|-------------------|
| GOVERN 1.4 | Oversight mechanisms | AI-HITL.1, AI-HITL.2 |
| GOVERN 1.5 | Ongoing monitoring plans | AI-MDL.3, AI-GRD.1 |
| GOVERN 1.7 | Privacy and civil liberties | AI-GRD.3, AI-FAIR.1 |
| MAP 2.3 | Fairness criteria defined | AI-FAIR.2 |
| MAP 4.1 | Data requirements | AI-DATA.1, AI-DATA.2, AI-DATA.3 |
| MEASURE 1.1 | Performance measurement | AI-MDL.3, AI-INF.2 |
| MEASURE 2.6 | Traceability of outputs | AI-INF.1 |
| MEASURE 2.9 | Confidence characterization | AI-EXPL.2 |
| MEASURE 2.11 | Fairness assessment | AI-FAIR.1, AI-FAIR.2 |
| MANAGE 1.3 | Deployment integrity | AI-MDL.1, AI-MDL.2 |
| MANAGE 2.2 | Performance monitoring | AI-INF.2, AI-INF.3 |
| MANAGE 2.4 | Resource allocation | AI-INF.3 |
| MANAGE 3.2 | Incident detection and response | AI-VIO.1, AI-SEC.1 |
| MANAGE 4.1 | Post-deployment monitoring plans | AI-HITL.2, AI-TOOL.1, AI-CHAIN.1, AI-SAFE.1 |

## 10. Security Considerations

### 10.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.

### 10.2 Factor Confidentiality

Factor values (especially `factor_a` thresholds) may reveal security posture
details (e.g., expected port counts, patch windows). Implementations SHOULD
apply access controls to factor data and leverage the Clearing Protocol
(Section 5.3) at Level 1 or higher for sensitive environments.

### 10.3 Clearing and Data Sovereignty

The Clearing Protocol (Section 5.3) is designed to prevent raw evidence from
becoming a persistent attack surface. However, implementations must consider:

- **Pre-clearing exfiltration:** An attacker with access during the Provenance
  phase (before clearing) can capture raw evidence. Clearing protects against
  post-anchoring data exposure, not real-time interception.
- **Factor inference:** Even at Clearing Level 1, retained factors may allow
  partial reconstruction of the original state (e.g., factor_b = 3 open ports
  reveals network topology). Clearing Level 2 or 3 is RECOMMENDED for
  environments where factor values themselves are sensitive.
- **Clearing verification:** Implementations SHOULD provide a mechanism to
  confirm that clearing has occurred (e.g., a clearing timestamp or clearing
  receipt). This supports SI-12 (Information Management and Retention) audit
  requirements.

### 10.4 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.

### 10.5 Collision Resistance

At 48 bits, the birthday paradox threshold is approximately 2^24 (~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 (Section 6.3) uses the full 64-character digest.

## 11. Conformance

An implementation is SWT3-conformant if it:

1. Produces anchors matching the format in Section 3
2. Uses only registered UCT codes from the UCT Registry (Section 3.2)
3. Computes fingerprints using the algorithm in Section 4
4. Can verify anchors using the algorithm in Section 6.1
5. Uses the JSON transport format in Section 8 for interoperability
6. Documents its Clearing Level (Section 5.3.1) in its security posture
7. Documents its AI Clearing Level (Section 9.3) if implementing AI procedures

An implementation claiming **SWT3-Sovereign** conformance MUST additionally:

8. Implement Clearing Level 1 or higher as the default behavior
9. Ensure clearing irreversibility per Section 5.3.3

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

## 12. IANA Considerations

This specification does not require any IANA registrations. The `SWT3` protocol
identifier and the UCT Registry are maintained by Tenable Nova LLC (DBA TeNova).
The UCT Registry governance process is defined in Section 3.2.5.

---

**Copyright (c) 2026 Tenable Nova LLC (DBA TeNova). Licensed under Apache 2.0.**

SWT3 and Sovereign Witness Traceability are trademarks of Tenable Nova LLC. Patent pending.

---

*SWT3: Sovereign Witness Traceability  --  Provenance, Verification, Clearing.*

## Appendix A: Version History

| Version | Date | Changes |
|---------|------|---------|
| 1.0.0 | 2026-02-26 | Initial specification. |
| 1.1.0 | 2026-03-15 | Canonical fingerprint formula with `WITNESS:` domain separator. Legacy fallback defined. |
| 1.2.0 | 2026-03-29 | AI Witnessing Profile (Section 9). UCT Extended codes. Protocol Lock (Phase 2). |
| 1.3.0 | 2026-04-17 | RFC 2119 notation. ABNF grammar. Section numbering fixes. Proposed Standard status. |
| 1.4.0 | 2026-05-03 | AI-DATA.3 (Training Data Statistics), AI-DATA.4 (Training Data PII Lifecycle). 42 total AI procedures. |
| 1.5.0 | 2026-05-23 | AI-FAIR.3 (Bias Audit), AI-CHAIN.2 (Chain Trust Credential), AI-ENV.1 (Runtime Environment), AI-ENV.2 (Dependency Manifest), AI-MARK.1 (Content Provenance), AI-BASE.1 (Agent Behavioral Baseline). 47 total AI procedures, 23 namespaces. |
| 1.6.0 | 2026-05-28 | AI-LIC.1 (License Provenance). 48 total AI procedures, 24 namespaces. |
| 1.7.0 | 2026-05-29 | AI-SBOM.1 (AI Bill of Materials), AI-REDTEAM.1 (Adversarial Test Campaign), AI-CONSENT.1 (Data Subject Consent), AI-MULTI.1 (Multi-Agent Delegation). 52 total AI procedures, 28 namespaces. |
| 1.8.0 | 2026-05-29 | AI-DRIFT.1, AI-AUDIT.1, AI-INCIDENT.1, AI-PERF.1, AI-ROBUST.1, AI-CYBER.1, AI-TRANS.1, AI-WATERMARK.1, AI-DPIA.1, AI-AUTO.1, AI-DUALUSE.1, AI-SUPPLY.1, AI-PMM.1. Full EU AI Act Art. 15 coverage (accuracy, robustness, cybersecurity), GDPR Art. 22/35, EO 14110, NIST MEASURE 3.1. 65 total AI procedures, 41 namespaces. |
| 1.9.0 | 2026-06-11 | AI-METAGOV.1 through AI-METAGOV.8 (Recursive Governance). AI-DEL.1 (Delegation), AI-CAP.1 (Capability), AI-COST.1 (Resource Consumption), AI-AUTO.3 (Autonomy Transition), AI-CLR.2 (Regulatory Transparency). 80 total AI procedures, 50 namespaces. |
| 1.10.0 | 2026-06-19 | AI-MOB.1 through AI-MOB.5 (Mobile Edge Governance). Platform-native witnessing for iOS, Android, visionOS. 85 total AI procedures, 51 namespaces. |
| 1.11.0 | 2026-07-10 | AI-EMRG.1 (Emergency Override Lifecycle), AI-DRIFT.2 (Consequence-Mapped Drift), AI-ASSESS.1 (Champion-Challenger Assessment). Lifecycle chain infrastructure with shared cycle_id linking. 88 total AI procedures, 53 namespaces. |
| 1.12.0 | 2026-07-14 | v6.0.0 "Operational Governance". AI-MOB.6 (Spatial Provenance), AI-MOB.7 (Compile-Time Detection), AI-SAMPLE.1 (Probabilistic Sampling). 111 total AI procedures across 61 namespaces. Lifecycle chain infrastructure finalized. |
| 2.0.0 | 2026-08-30 | Four new namespace clusters: NHI (Non-Human Identity, 6 procedures), HBOM (Hardware Bill of Materials, 6 procedures), DPP (Digital Product Passport, 4 procedures), ADR (Automated Demand Response, 6 procedures). Protocol extends beyond AI governance to infrastructure identity, physical product lifecycle, and energy grid compliance. 266 total procedures across 9 top-level namespaces. 36 frameworks. SDKs in 10 languages. |

## Appendix B: Intellectual Property

Certain aspects of the SWT3 protocol and its implementations are covered by
one or more patent applications held by TeNova Labs. The protocol specification
is published under Apache 2.0. Implementations are free to use, modify, and
distribute. Patent protection covers specific commercial implementations and
platform features, not the open protocol itself.