How SWT3 Clearing Levels map to defense industrial base requirements
Who this is for: ISSMs, security engineers, C3PAO assessors, and compliance officers working with systems that handle Controlled Unclassified Information (CUI). If you are evaluating TeNova Axiom for a CMMC Level 2 or Level 3 system, this document tells you which clearing level to choose, which controls it satisfies, and what to show an assessor.
Use this table to choose the right clearing level for your environment. If you are unsure, start with Level 2. It provides the strongest balance of auditability and data protection for CUI systems. You can always move to Level 3 later, but you cannot retroactively raise the clearing level on existing anchors.
| Your environment | Recommended level | Why |
|---|---|---|
| Development or staging (no CUI) | Level 0 or 1 | Full audit trail with no regulatory data at risk |
| Production with CUI | Level 2 | Meets MP-6, SI-12, and SC-28 without exposing operational metadata |
| Air-gapped or classified enclave | Level 3 | Zero-knowledge proof; TeNova sees nothing identifiable |
| Managed service (you host for others) | Level 2 minimum | Your tenants' metadata is their CUI, not yours to share |
CMMC requires: CUI is sanitized from media before disposal or reuse.
How SWT3 addresses it: At Clearing Level 2 and above, contextual metadata (provider names, guardrail configurations, system fingerprints) is destroyed before transmission. At Level 3, all identifying information is destroyed after the anchor is sealed. The SDK's clearing engine operates on the wire payload and then purges local temporary buffers.
The clearing engine source code in the published SDK (Python: swt3_ai/clearing.py, TypeScript: src/clearing.ts). Point them to the _apply_clearing function which implements the per-level sanitization logic. The code is open source and auditable.
CMMC requires: CUI is retained and disposed of in accordance with applicable laws, regulations, and organizational policies.
How SWT3 addresses it: The four clearing levels give you explicit, configurable control over what is retained and what is disposed of. Your clearing level selection becomes part of your system security plan. The Factor Handoff Protocol defines how disposed data is transferred to your custody before destruction, creating a documented chain of custody.
Your clearing level configuration in the SDK, the Factor Handoff Protocol specification, and your organization's factor backup and retention procedure. The assessor should see that you made a deliberate, documented choice about data retention, not that data was silently discarded.
CMMC requires: Integrity verification of software and security-relevant information.
How SWT3 addresses it: Every SWT3 Witness Anchor is a SHA-256 fingerprint that seals the compliance fact at the moment it was observed. If any factor is altered after the fact, the fingerprint will not match on re-verification. The daily enclave signature binds all anchors into a tamper-evident chain. Altering one anchor breaks the chain.
Run a verification on any anchor using the public verifier or the offline verification formula. Demonstrate that the math matches. Then show the enclave signature and explain that it binds all anchors for the period into a single root hash.
CMMC requires: CUI at rest is protected.
How SWT3 addresses it: At Clearing Level 2 and above, the sensitive metadata never reaches TeNova's systems, so there is nothing to protect at rest on our side. On your side, the Factor Handoff Protocol supports encrypted storage via Cloud KMS Envelope (AES-256-GCM with a key you control) or HashiCorp Vault.
Your factor storage configuration (Vault path, KMS key ARN, or encrypted filesystem) and your factor backup encryption policy.
CMMC requires: CUI in transit is protected.
How SWT3 addresses it: All communication between the SWT3 SDK and TeNova uses HTTPS (TLS 1.2 or higher). The webhook handoff method enforces HTTPS and rejects plaintext connections. At Level 3, even if the transmission were intercepted, the payload contains only numeric factors and a hashed model ID with no identifying context.
The SDK's TLS enforcement (the webhook method rejects HTTP), your platform's TLS configuration, and the Caddy reverse proxy HSTS headers on the TeNova endpoint.
CMMC requires: Access to CUI is enforced based on applicable policies.
How SWT3 addresses it: Clearing level selection is a configuration-time decision made by the system administrator. The SDK enforces the selected level programmatically; individual users cannot override it at runtime. Factor handoff destinations (Vault paths, webhook URLs, KMS keys) are set in configuration, not chosen per-request.
Your SDK configuration showing the clearing level and handoff destination. Demonstrate that a developer using the SDK cannot change the clearing level without modifying the system configuration.
CMMC requires: Audit records contain enough information to establish what happened, when, where, and the outcome. Records must be retained for a defined period.
How SWT3 addresses it: Every SWT3 Witness Anchor records the procedure ID (what), the timestamp (when), the tenant ID (where), the verdict (outcome), and the three factors (the evidence). Anchors on the TeNova ledger are permanent and do not expire. For factors held on your systems (Levels 2 and 3), retention is your responsibility. For most NIST 800-171 environments, three years is the baseline.
A sample anchor from your ledger. Walk through the SWT3 format: SWT3-{TIER}-{PROVIDER}-{UCT}-{PROCEDURE}-{VERDICT}-{EPOCH}-{FINGERPRINT}. Each field maps to one of the AU-3 requirements. For AU-11, show your factor retention policy and evidence that your backup/restore process has been tested.
CMMC requires: Authenticators (passwords, tokens, keys) are managed securely.
How SWT3 addresses it: Factor handoff credentials (Vault tokens, webhook bearer tokens, KMS key references) are authenticators under IA-5. The Factor Handoff Protocol recommends dedicated, scoped credentials for each handoff method. Vault tokens should be limited to create on the SWT3 factor path. Webhook tokens should be single-purpose.
Your Vault policy or webhook credential management procedure. Demonstrate that the handoff token cannot access anything beyond the SWT3 factor storage path.
If your system includes AI components and you are using the SWT3 AI Witness SDK, these additional mappings apply. For organizations subject to the NIST AI RMF, the procedures map to MAP 1.1, MEASURE 2.6, and MANAGE 3.2 respectively.
The SDK witnesses every AI inference and creates an anchor proving the model, inputs, and outputs were recorded. At Clearing Level 2 and above, the raw inputs and outputs stay on your system. Only hashes are transmitted.
The SDK records a hash of the model identifier at inference time. If the model changes between inferences, the hash changes and the drift is detectable.
The SDK records how many guardrails were required, how many were active, and whether they passed. At Clearing Level 2 and above, the guardrail names are stripped, but the numeric compliance fact (required vs. active) is preserved.
When a C3PAO assessor asks about SWT3 and data handling, use this table to find the right answer quickly.
| Assessor question | Where to look |
|---|---|
| "How is CUI protected during AI witnessing?" | Clearing Level definitions in the ToS Addendum, Section A. Level 2 and above strips all identifying metadata. |
| "How do you prove data was actually cleared?" | Clearing engine source code in the open-source SDK. The _apply_clearing function is auditable. |
| "What if the vendor is breached?" | ToS Addendum, Section E (Incident Response). At Level 3, exposure is near zero by design. |
| "Where are the factors stored?" | Factor Handoff Protocol, Section 3. Client chooses: local file, webhook, Vault, or KMS. |
| "What happens if factors are lost?" | ToS Addendum, Section D. The anchor is intact but un-verifiable. Client holds sole custody. |
| "How do you handle incorrect verdicts?" | ToS Addendum, Section F. Revocation record appended; original anchor stays for integrity. |
| "What is the retention period?" | Anchors on TeNova are permanent. Client-held factors follow the client's retention schedule. |
| "Can I verify an anchor independently?" | Factor Handoff Protocol, Section 5. Offline verification with a 4-line code snippet. No TeNova dependency. |
| "Is the protocol proprietary?" | No. Open-source SDKs, published spec, public verifier. Patent pending on the implementation, not the math. |
| "How does this map to 800-171?" | This document. See Control-by-Control Mapping above. |
When documenting SWT3 in your System Security Plan, consider language similar to the following. Adjust to match your system specifics.
This overlay references and depends on: