Overview
The Axiom Validation Harness is a three-stage protocol that proves two things to any auditor, examiner, or CISO:
- Mathematical Fidelity - the SWT3 Witness Anchor reflects the exact logic of the AI model.
- Privacy Enforcement - sensitive data is physically impossible to recover from the ledger.
This SOP is designed for customer onboarding. It runs in your sandbox or QA environment, never in production. No production PII is required. The protocol produces a tamper-evident audit anchor that serves as your Validation Certificate.
Build vs. Buy: Running this harness requires the SDK, the ledger, the clearing engine, and the integrity layer. Axiom provides all four. Building them internally is 6-12 months of engineering. This harness runs in 10 minutes.
The Three Stages
Factor Selection
Objective: Define which 5-10 factors the Axiom SDK will witness for your model.
Duration: Day 1-2
Select procedures from the UCT Registry that match your model's safety logic. For each procedure, map your model's output to the three SWT3 factors (A, B, C).
Example: Fraud Detection Model
| Procedure | Factor A (Standard) | Factor B (Observed) | Factor C (Context) |
|---|---|---|---|
| AI-INF.1 | Max latency (ms) | Actual latency | Cache hit flag |
| AI-INF.2 | Expected model hash | Running model hash | Version mismatch |
| AI-GRD.1 | Guardrail threshold | Guardrail score | Override flag |
| AI-FAIR.1 | Max disparity ratio | Observed disparity | Protected class count |
| AI-MDL.1 | Approved weight hash | Running weight hash | Drift detected |
Deliverable: A Factor Matrix Map connecting your model outputs to Axiom procedures. This is shared between your engineering team and the Axiom operator.
Leakage Audit (Entropy Validation)
Objective: Prove that zero sensitive data survives into the Axiom ledger.
Duration: Day 3-7
The Leakage Audit uses Axiom's proprietary canary injection engine to test data purging across all four Clearing Levels (0-3). Synthetic PII representing 8 data categories (identifiers, financial, medical, contact, and location data) is processed through the AI Witness SDK. An automated search then verifies that zero raw data survives into the persistence layer.
Running the Audit
# In the Axiom container: docker exec axiom-engine entrypoint.sh validate leakage-test
Expected Results by Clearing Level
| Level | Name | Raw PII in Ledger | Expected Result |
|---|---|---|---|
| 0 | Analytics | Hashed only | PASS (hashes present, raw strings absent) |
| 1 | Standard | None | PASS (zero canaries found) |
| 2 | Sensitive | None | PASS (zero canaries, no metadata) |
| 3 | Classified | None | PASS (numeric factors only) |
Success Criteria: Zero raw PII canary strings found in the persistence layer at any clearing level. If a single canary is found, the audit FAILS.
Deliverable: The leakage audit produces a SWT3 Witness Anchor for the audit itself - recursive integrity. This anchor IS the Validation Certificate. No separate document needed.
Anchor Integrity (Drift Detection)
Objective: Prove the integrity layer detects anomalies when a model drifts.
Duration: Day 8-10
Force a controlled "safety violation" in the test model - change a guardrail threshold, swap a model weight, or inject a confidence score below the clinical threshold. The Axiom SDK should:
- Record the inference with a FAIL verdict (factor_b violates factor_a).
- The integrity layer flags the anomaly in the next rollup cycle.
- If drift alerting is configured, an alert fires within the monitoring window.
Success Criteria: The forced drift produces a FAIL anchor, the integrity rollup reflects the change, and the drift alert fires (if configured). This proves the system catches real problems, not just passes everything.
14-Day Onboarding Timeline
Boardroom Deliverables
At the end of the 14-day onboarding, you present three artifacts:
- Validation Certificate - The SWT3 anchor from the leakage audit, verifiable at sovereign.tenova.io/verify. Proves the clearing engine works with zero data leakage.
- Factor Matrix Map - The signed document showing which model outputs map to which SWT3 procedures. Proves the witness sees the right things.
- Live Dashboard - Real-time accountability posture. Pass rate, drift detection, inference timeline, and per-model detail. The ongoing proof.
The Close: "We don't just trust our code. We run it through our Validation Harness. We've already proven that Axiom witnesses your model's safety logic without ever seeing your customers' private data. Here is the Leakage Audit report from our last run."
Clearing Level Reference
| Level | Name | What Leaves the Wire | Use Case |
|---|---|---|---|
| 0 | Analytics | Hashed prompts/responses + all metadata | Internal dashboards, non-sensitive workloads |
| 1 | Standard | Numeric factors + model metadata | Most enterprise deployments (default) |
| 2 | Sensitive | Numeric factors only | Healthcare (PHI), financial (PCI), legal |
| 3 | Classified | Numeric factors, no model identifiers | Defense, classified environments, SCIF |
Full details: SWT3 ToS Clearing Addendum
Industry Coverage
The Validation Harness works across all five Axiom verticals. The canary types are designed to cover PII patterns from each industry:
| Vertical | Framework | Key Canary Types | Recommended Clearing Level |
|---|---|---|---|
| AI Accountability | EU AI Act, NIST AI RMF | Names, emails, prompts | Level 1 (Standard) |
| Defense / GovCon | NIST 800-53, CMMC, FedRAMP | All types, classified data | Level 3 (Classified) |
| Financial Services | SR 11-7 | SSNs, credit cards, account numbers | Level 2 (Sensitive) |
| Healthcare | HIPAA, 21 CFR Part 11 | PHI, medical records, patient IDs | Level 2 (Sensitive) |
| Construction | OSHA 1926 | Contractor IDs, site photos, addresses | Level 1 (Standard) |
Document Lineage
- SWT3 ToS Clearing Addendum - shared responsibility, clearing levels, incident response
- Factor Handoff Protocol - factor custody at Clearing Level 2+
- UCT Registry - 162 procedures across 5 industry domains
- SDK Documentation - integration guides for Python and TypeScript
- SWT3 Anchor Verifier - independent verification, zero vendor dependency