How to Conduct an AI Compliance Assessment: Operational Playbook for Auditors and Notified Bodies

Audience: EU AI Act Notified Body evaluators, CMMC C3PAO assessors, SR 11-7 model risk auditors, ISO 42001 governance consultants, and internal AI audit teams. No prior SWT3 experience required.

Notified Body

EU AI Act Conformity

Art. 9-15, Art. 50, Art. 62

Start at Section 6 Core: Sections 1-5

C3PAO Assessor

CMMC / NIST 800-53

AU, AC, SI, CA families

Start at Section 7 Core: Sections 1-5

Bank Auditor

SR 11-7 Model Risk

OCC/Fed Reserve examination

Start at Section 8 Core: Sections 1-5

Governance Consultant

ISO 42001 / Multi-Framework

Client advisory, gap analysis

Start at Section 9 Core: Sections 1, 4, 9

1. What is SWT3? (The 5-Minute Explanation) 2. Anatomy of a Witness Anchor 3. The Assessment Workflow (7 Steps) 4. UCT Registry Quick Reference 5. Evidence Artifacts Reference 6. EU AI Act Playbook (Notified Body) 7. CMMC / NIST 800-53 Playbook (C3PAO) 8. SR 11-7 Playbook (Bank Auditor) 9. ISO 42001 / Multi-Framework (Governance Consultant) 10. Verification Walkthrough 11. Common Assessment Findings 12. Glossary 13. Related Guides

1. What is SWT3?

SWT3 is an open witness protocol for AI systems. It creates per-event cryptographic evidence records called Witness Anchors that prove a compliance-relevant activity occurred, when it occurred, and what the outcome was.

The notary analogy: A notary does not approve or reject a document. A notary witnesses that a signing occurred, records the date, and produces a tamper-evident seal. SWT3 does the same for AI inferences, model deployments, access control events, and risk management activities. It does not enforce policy. It witnesses.

How it works

  AI system operates         SDK witnesses the event       Anchor is minted            Anchor stored in ledger
  (inference, tool call,  ->  (captures hashes, factors, ->  (SHA-256 fingerprint,   ->  (immutable, verifiable
   access decision)            timestamps locally)            signed, timestamped)        by any party)

Raw prompts and responses never leave the deployment infrastructure. The SDK computes SHA-256 hashes locally and transmits only irreversible hashes and numeric factors. This means compliance evidence exists without exposing proprietary content.

Traditional evidence vs. cryptographic evidence

Dimension	Traditional (Logs, Screenshots)	Cryptographic (SWT3 Anchors)
Tamper resistance	Logs can be edited after the fact	SHA-256 fingerprint detects any modification
Continuity	Gaps are invisible (you cannot prove nothing happened)	Gaps in the anchor chain are detectable and provable
Verifiability	Requires trust in the evidence producer	Any party can independently recompute and verify
Timeliness	Periodic snapshots (daily, weekly)	Per-event (every inference, every tool call)
Vendor independence	Evidence locked in vendor platform	Open protocol, verifiable from any browser

2. Anatomy of a Witness Anchor

Every compliance event produces a Witness Anchor. Understanding the anchor format is essential for verification.

SWT3-E-AWS-AI-AIINF1-PASS-1773316622-a1b2c3d4e5f6

Segment	Example	Meaning
Tier	SWT3-E	Deployment tier: E = Enclave, S = SaaS, H = Hybrid
Provider	AWS	Infrastructure provider (AWS, AZURE, GCP, etc.)
UCT Domain	AI	Control domain from the Universal Control Taxonomy
Procedure	AIINF1	Specific procedure (AI-INF.1 = Inference Provenance)
Verdict	PASS	Deterministic result: PASS or FAIL
Epoch	1773316622	Unix timestamp (seconds) when the event occurred
Fingerprint	a1b2c3d4e5f6	First 12 characters of the SHA-256 hash

Factor semantics

Each anchor records three numeric factors that capture the measurable aspects of the compliance event:

Factor	General Meaning	AI-INF.1 Example	AI-PERF.1 Example	AI-SUPPLY.1 Example
Factor A	Threshold or count	Provenance required (1)	Metrics evaluated (5)	Suppliers assessed (3)
Factor B	Observed value	Provenance captured (1)	Metrics passing (5)	Suppliers compliant (3)
Factor C	Context or metadata	Reserved (0)	Benchmark type code	Risk level code

Assessor tip: The exact meaning of each factor depends on the procedure. Always cross-reference against the UCT Registry Reference to confirm what Factor A, B, and C represent for the specific procedure you are reviewing.

Clearing levels

Organizations configure how much detail is transmitted in each anchor. Ask the provider which clearing level they use.

Level	Name	Data Transmitted	Assessor Implication
0	Analytics	Hashes + factors + model + provider + guardrails + context	Maximum transparency. Full verification possible.
1	Standard	Hashes + factors + model + provider	Good transparency. Most assessments use this level.
2	Sensitive	Hashes + factors + model only	Provider identity stripped. Ask provider to supplement.
3	Classified	Numeric factors only, model ID hashed	Minimal detail. Requires supplemental documentation.

Fingerprint formula

Every anchor's fingerprint is computed from a locked, cross-language formula:

SHA256("WITNESS:" + tenant_id + ":" + procedure_id + ":" + factor_a + ":" + factor_b + ":" + factor_c + ":" + timestamp_ms).hex()[:12]

This formula is identical in Python, TypeScript, Rust, C#, and Ruby. You can independently recompute any fingerprint using only the factor values and timestamp. No vendor access required.

3. The Assessment Workflow

These seven steps work regardless of your regulatory framework. Follow them in order for your first assessment. After that, adapt the sequence to your methodology.

Request the evidence package

Ask the organization for their compliance evidence export. Three formats are available:

Compliance Passport: One-page HTML summary of compliance posture. Good for initial review.
OSCAL Bundle: Machine-readable SSP + POA&M + Assessment Results. Compatible with eMASS and GRC tools.
AI Witness Export: Full JSON ledger of all witness anchors with factor data. Best for detailed review.

If the organization provides an auditor portal token, you can access all evidence directly via the web interface at /audit/{token}.

Verify anchor integrity

Use the public verification page to spot-check anchors. Enter any anchor fingerprint. The page computes SHA-256 entirely in your browser with zero vendor dependency. If the computed hash matches, the anchor has not been tampered with.

You can also verify offline by recomputing the fingerprint formula yourself using the factor values and timestamp from the evidence export.

Check evidence continuity

Review the posture trend over the assessment period. Look for:

Continuous PASS chains: Sustained compliance for that procedure.
Gaps in the timeline: Periods where no anchors were minted. Could indicate an outage, a misconfiguration, or evidence collection was paused. Ask the organization to explain any gaps.
FAIL followed by PASS: Indicates an issue was detected and remediated. Check the POA&M for the corresponding entry.

Examine verdicts by procedure

For each procedure in your assessment scope, review the verdict history. Cross-reference the procedure ID against the UCT Registry to confirm it maps to your regulatory requirement. Three verdict types:

PASS: The evaluation expression was satisfied. Factor values met the threshold.
FAIL: The evaluation expression was not satisfied. Does not necessarily mean non-compliance -- check whether the issue was remediated and documented in the POA&M.
INHERITED: The control responsibility lies with the infrastructure provider (e.g., cloud provider physical security). Verify the inheritance chain is documented.

Validate factor semantics

For key procedures, confirm that the factor values are meaningful:

Are Factor A values consistent with the organization's stated thresholds?
Are Factor B values within expected operational ranges?
Do Factor C context codes match the organization's declared configuration?

Example: For AI-PERF.1 (Performance Monitoring), Factor A = metrics evaluated, Factor B = metrics passing. If the organization claims they monitor 10 performance metrics, Factor A should be 10, not 1.

Check for revocations

Query the evidence for AI-REV.1 (Anchor Revocation) entries. A revoked anchor means the organization identified unreliable results and formally invalidated them. Seven reason codes are defined:

0 = Unspecified, 1 = Model recall, 2 = Policy violation, 3 = Data contamination
4 = Consent withdrawal, 5 = Regulatory order, 6 = Error correction

Revocations are a positive signal -- they demonstrate the organization has a functioning error correction process. Ask for documentation explaining each revocation.

Form your assessment opinion

Map the evidence to your framework's requirements. For each requirement, classify the coverage:

Full Evidence alone satisfies the requirement. No supplemental documentation needed.
Partial Evidence supports the requirement but organizational documentation is also needed (e.g., risk acceptance statements, governance minutes).
Customer Requirement is outside the scope of automated evidence. The organization must provide documentation separately.

Decision tree

Is the anchor fingerprint valid? YES -> Is the evidence chain continuous (no unexplained gaps)? YES -> Do factor values match stated policy thresholds? YES -> Evidence supports compliance for this procedure. NO -> Document finding. Request explanation from provider. NO -> Document gap. Request incident report or explanation. NO -> CRITICAL FINDING. Evidence may have been tampered with. Escalate immediately. Request original evidence and audit logs.

4. UCT Registry Quick Reference

The Universal Control Taxonomy (UCT) is the catalog of all witnessable compliance events. Each procedure has a unique ID, three factor definitions, a deterministic evaluation expression, and cross-references to applicable regulatory frameworks. The full registry contains 204 procedures across 46 namespaces.

Key AI namespaces for assessors

Namespace	Focus Area	Procedures	Typical Regulatory Mapping
AI-INF	Inference integrity	3	EU AI Act Art. 12, NIST MEASURE 2.6
AI-GRD	Guardrail enforcement	3	EU AI Act Art. 9, NIST GOVERN 1.4
AI-MDL	Model governance	7	SR 11-7, NIST MAP 3.5
AI-FAIR	Bias and fairness	3	EU AI Act Art. 10, NIST MEASURE 2.5
AI-HITL	Human oversight	2	EU AI Act Art. 14
AI-EXPL	Explainability	2	EU AI Act Art. 13, NIST MEASURE 2.8
AI-DATA	Data governance	4	EU AI Act Art. 10, GDPR Art. 25
AI-CHAIN	Chain of custody	2	EU AI Act Art. 9, Multi-agent traceability
AI-SUPPLY	Supply chain risk	1	NIST MEASURE 3.1, EO 14028
AI-PERF	Performance monitoring	1	EU AI Act Art. 15(1), NIST MEASURE 2.5
AI-ROBUST	Robustness testing	1	EU AI Act Art. 15(3), NIST MEASURE 2.6
AI-INCIDENT	Incident reporting	1	EU AI Act Art. 62, NIST MANAGE 3.2
AI-DRIFT	Model drift	1	EU AI Act Art. 9(2)(b), Ongoing monitoring
AI-REV	Anchor revocation	1	Error correction, model recall
AI-CYBER	Cybersecurity	1	EU AI Act Art. 15(4), NIST CSF

For the complete 78-procedure AI catalog with factor definitions and evaluation expressions, see the UCT Registry Reference.

How to read a procedure entry

Example: AI-INF.1 (Inference Provenance)

Field	Value	What It Means for Assessors
ID	AI-INF.1	Unique identifier. Use this in your assessment report.
Factor A	provenance_required	Was provenance collection expected? (1 = yes)
Factor B	provenance_captured	Was it actually captured? (1 = yes)
Factor C	reserved	Not used in this procedure.
Evaluation	`factor_b >= factor_a`	PASS if captured meets or exceeds required.
Frameworks	EU AI Act Art. 12(1)	This procedure provides evidence for Art. 12 logging.

5. Evidence Artifacts Reference

What You Need	Artifact	How to Get It	Format
Overall compliance posture	Compliance Passport	`/api/v1/passport/export`	HTML or signed JSON
Machine-readable package	OSCAL Bundle	OSCAL export	SSP + POA&M + AR (XML/JSON)
AI model audit trail	AI Witness Export	`/api/v1/ai-witness/export`	Auditor JSON
Remediation roadmap	Gap-to-Green Report	Gap analysis page	HTML (9 sections)
Continuous monitoring data	Posture Trend	Command page	90-day trend visualization
Single anchor verification	Public Verifier	/verify	Client-side (no credentials needed)
Tamper evidence	Merkle Proof	`/api/v1/merkle/proof?fingerprint=xxx`	JSON (proof path)
Open vulnerability status	POA&M	OSCAL export or Settings page	OSCAL XML/JSON
Conformity checklist	Annex IV Checklist	Auditor portal	14-section progress tracker

Assessor tip: You do not need platform access to verify an anchor. The /verify page runs entirely client-side using SHA-256 in your browser. You can verify evidence integrity without credentials, accounts, or vendor dependency. This is by design.

6. EU AI Act Playbook

For Notified Body evaluators conducting conformity assessment under the EU AI Act.

Article 9: Risk Management System

Requirement: A risk management system shall be established, implemented, documented, and maintained.

SWT3 evidence: AI-GRD.1 (guardrail enforcement), AI-GRD.2 (guardrail coverage), AI-SAFE.1 (safety constraints). Continuous PASS chains demonstrate the risk management system is operational, not just documented.

Assessor action: Verify that guardrail procedures have been active for the full assessment period. Check factor values: Factor A (guardrails required) should match the organization's risk management plan.

Gap alert: SWT3 does not produce the risk management plan itself. The organization must provide the documented plan separately. SWT3 provides evidence that the plan's technical controls are being enforced.

Article 11: Technical Documentation

Requirement: Technical documentation shall be drawn up before the system is placed on the market (Annex IV).

SWT3 evidence: The Annex IV checklist (available in the auditor portal) tracks 14 documentation sections with completion status. AI-MDL.5 (model weights), AI-MDL.6 (adapter stack), and AI-DATA.1/DATA.2 (training data) provide cryptographic evidence of model and data provenance.

Assessor action: Review the checklist for COMPLETE vs. PARTIAL sections. For PARTIAL sections, request supplemental documentation.

Article 12: Record-Keeping

Requirement: Automatic logging of events during the AI system's lifecycle.

SWT3 evidence: AI-INF.1 (inference provenance) and AI-AUDIT.1 (audit trail integrity) provide per-event cryptographic records. Every inference call generates a witness anchor with timestamp, model ID, and factor values.

Assessor action: Verify the anchor chain is continuous for the assessment period. Any gaps constitute a logging failure. Check that the logging granularity (per-inference vs. periodic) matches the organization's risk classification.

Article 14: Human Oversight

Requirement: The AI system shall be designed to allow effective human oversight.

SWT3 evidence: AI-HITL.1 (human-in-the-loop checkpoint) and AI-HITL.2 (human override capability). These procedures record when human oversight was exercised and the outcome.

Assessor action: Verify that HITL procedures are active. Check Factor A (oversight required) vs. Factor B (oversight exercised). A consistent gap between A and B indicates oversight is configured but not being exercised.

Article 15: Accuracy, Robustness, Cybersecurity

Requirement: The AI system shall achieve appropriate levels of accuracy, robustness, and cybersecurity.

SWT3 evidence: AI-PERF.1 (performance metrics), AI-ROBUST.1 (robustness testing), AI-CYBER.1 (cybersecurity assessment). Each procedure records the number of tests/controls and how many passed.

Assessor action: For AI-PERF.1, verify that the metrics evaluated (Factor A) match the organization's declared KPIs. For AI-ROBUST.1, check that the survival rate (Factor B / Factor A) meets the organization's stated threshold (typically >= 90%).

Article 50: AI-Generated Content

Requirement: Content generated by AI shall be marked as such.

SWT3 evidence: AI-MARK.1 (content provenance witnessing). Records content type, marking method (C2PA, watermark, metadata), and whether marking was applied.

Assessor action: Verify AI-MARK.1 anchors exist for content-generating systems. Check that the marking method matches the organization's declared approach.

Article 62: Serious Incident Reporting

Requirement: Providers shall report serious incidents to market surveillance authorities.

SWT3 evidence: AI-INCIDENT.1 (incident witnessing). Records severity code, whether authorities were notified, and incident type classification.

Assessor action: Cross-reference AI-INCIDENT.1 anchors against the organization's incident register. Each incident should have a corresponding anchor with Factor B = 1 (authority notified) for serious incidents.

Gap alert: SWT3 records that an incident was documented and reported. It does not generate the incident report content or submit notifications to authorities. The organization must demonstrate the actual reporting separately.

7. CMMC / NIST 800-53 Playbook

For C3PAO assessors evaluating AI workloads under CMMC Level 2 or NIST 800-53.

Where AI procedures fit in your assessment

AI procedures supplement your traditional control checks. They do not replace the standard assessment methodology -- they add evidence for AI-specific workloads that existing controls do not fully address.

CMMC Domain	Traditional Controls	AI Supplement (UCT Procedures)
AU (Audit)	AU-2, AU-3, AU-6	AI-INF.1, AI-AUDIT.1 (per-inference audit records)
AC (Access Control)	AC-2, AC-3, AC-6	AI-ACC.1 (agent access scope verification)
SI (System Integrity)	SI-4, SI-7	AI-DRIFT.1 (model integrity monitoring), AI-ROBUST.1
CA (Assessment)	CA-2, CA-7	AI-PMM.1 (continuous monitoring evidence)
SC (Communications)	SC-7, SC-8	AI-CYBER.1 (cybersecurity controls for AI components)
SR (Supply Chain)	SR-1 through SR-12	AI-SUPPLY.1 (AI model/component supply chain risk)

OSCAL compatibility

The OSCAL export bundle is compatible with eMASS and standard GRC tools. Two adjustments may be needed before import:

Replace the system-id with your organization's assigned system identifier.
Map POA&M risk-level values to your organization's risk nomenclature if different from CRITICAL/HIGH/MEDIUM/LOW.

Assessor tip: During your CMMC Level 2 assessment, treat AI procedures as supplemental evidence for the AU, AC, and SI families. Document them in the same assessment report format you use for traditional controls. The verdict (PASS/FAIL) and factor values provide the quantitative evidence that supports your finding.

8. SR 11-7 Playbook

For model risk auditors preparing for OCC or Federal Reserve examination.

SR 11-7 Area	Examiner Question	SWT3 Evidence to Present
Model Inventory	"Show me your model inventory."	AI Witness Export filtered by `ai_model_id`. Each model has a full anchor history with versions, checksums, and deployment timestamps.
Ongoing Monitoring	"How do you monitor model performance?"	AI-PERF.1 and AI-DRIFT.1 anchor chains. Continuous PASS chains demonstrate monitoring was active at every interval. Any FAIL creates an auditable record of when drift was detected.
Validation	"How was this model independently validated?"	AI-ROBUST.1 (robustness testing results), AI-FAIR.1 (bias testing results). Factor values show the number of tests and pass rates.
Governance	"Who approved this model for production?"	AI-HITL.1 (human oversight checkpoint). Factor B = 1 confirms a human approved the deployment. Timestamp proves when approval occurred.
Change Management	"What changed between model versions?"	AI-MDL.5 (model weights hash), AI-MDL.6 (adapter stack). Different hash values between versions prove the model changed. The anchor history shows exactly when.

Assessor tip: When the examiner asks to see your ongoing monitoring framework, present the AI Witness ledger filtered by AI-PERF.1 and AI-DRIFT.1. The continuous anchor chain is stronger evidence than a monitoring policy document because it proves monitoring was actually happening, not just planned.

9. ISO 42001 / Multi-Framework Playbook

For governance consultants advising clients across multiple regulatory frameworks.

The multi-framework value

A single SWT3 anchor simultaneously satisfies requirements across multiple frameworks. This is the core efficiency argument for your clients:

UCT Procedure	EU AI Act	NIST AI RMF	CMMC	SR 11-7
AI-INF.1	Art. 12 (logging)	MEASURE 2.6	AU-2	Ongoing monitoring
AI-GRD.1	Art. 9 (risk mgmt)	GOVERN 1.4	SI-7	Controls
AI-PERF.1	Art. 15(1) (accuracy)	MEASURE 2.5	CA-7	Validation
AI-FAIR.1	Art. 10 (data quality)	MEASURE 2.5	--	Validation
AI-HITL.1	Art. 14 (oversight)	GOVERN 1.3	--	Governance
AI-SUPPLY.1	Art. 15(4)	MEASURE 3.1	SR-1	Vendor mgmt
AI-INCIDENT.1	Art. 62 (reporting)	MANAGE 3.2	IR-6	Incident mgmt
AI-DRIFT.1	Art. 9(2)(b)	MEASURE 2.6	SI-4	Ongoing monitoring

Client recommendation

When recommending an evidence platform to clients operating under multiple frameworks, the key decision factors are: (1) Does the evidence survive independent verification? (2) Does one evidence stream satisfy multiple frameworks? (3) Can the assessor verify independently of the vendor? SWT3 answers yes to all three. A single integration produces evidence that maps across EU AI Act, NIST AI RMF, CMMC, SR 11-7, and ISO 42001 simultaneously, and any party can verify the evidence using only a web browser and the published fingerprint formula.

10. Verification Walkthrough

You can verify any SWT3 anchor independently, without credentials or vendor access.

Browser verification (recommended for spot-checks)

Navigate to sovereign.tenova.io/verify
Paste an anchor token or fingerprint into the input field
Enter the tenant ID, procedure ID, factor values, and timestamp from the evidence export
The page computes SHA-256 entirely in your browser (no server call is made)
If the computed fingerprint matches the anchor's fingerprint: CERTIFIED TRUTH -- the anchor is intact
If the fingerprints do not match: TAMPERED -- the anchor or the factor values have been modified

Offline verification (for classified or air-gapped environments)

If you cannot use a browser, compute the fingerprint manually:

echo -n "WITNESS:tenant_id:AI-INF.1:1:1:0:1773316622000" | sha256sum | cut -c1-12

Compare the result against the fingerprint in the anchor. If they match, the evidence is intact. This works on any system with a SHA-256 implementation.

Assessor tip: For your first assessment, verify at least 5 anchors manually using the public verify page. This builds your confidence in the evidence integrity and provides documentation that you independently verified the evidence. Record the verification results in your assessment notes.

11. Common Assessment Findings

Informational

Gap in evidence timeline

What it looks like: No anchors minted for a procedure during a specific time window.

What it means: Could be a planned maintenance window, a provider outage, or evidence collection was temporarily disabled. The absence of evidence IS evidence -- it proves something interrupted the normal pattern.

What to do: Ask the organization to explain the gap. If they have an incident record or maintenance log covering the period, the gap is explained. If they cannot explain it, document it as a finding.

Minor

FAIL verdict in the ledger

What it looks like: One or more anchors show a FAIL verdict for a procedure.

What it means: The evaluation expression was not satisfied at that point in time. This does not automatically mean non-compliance. Check whether a corresponding POA&M entry exists and whether remediation was completed.

What to do: Review the POA&M. If the FAIL was remediated within the prescribed milestone (CRITICAL: 7 days, HIGH: 30 days, MEDIUM: 90 days), document it as a resolved finding. If it remains open, document it as an open finding with the remediation timeline.

Positive

Revoked anchor (AI-REV.1)

What it looks like: An AI-REV.1 anchor referencing a previously minted anchor.

What it means: The organization identified an unreliable result and formally invalidated it. The original anchor remains in the ledger (immutability preserved), but its status is marked as revoked.

What to do: Review the reason code. Ask the organization to explain the circumstances. Document this as a positive indicator of error correction capability. The existence of revocations demonstrates a functioning quality management process.

Informational

INHERITED verdict

What it looks like: A procedure shows INHERITED instead of PASS or FAIL.

What it means: The control responsibility lies with the infrastructure provider (e.g., cloud provider handles physical security, encryption at rest). The organization is inheriting the provider's compliance for this control.

What to do: Verify that the provider's compliance claim is documented (e.g., SOC 2 report, ISO 27001 certificate). Ask for the provider inheritance matrix. Inheritance is standard practice but must be explicitly documented and periodically verified.

Minor

Clearing level mismatch

What it looks like: Factor values or model identifiers are missing or hashed in the evidence export.

What it means: The organization configured a high clearing level (Level 2 or 3) that strips context information. This is a legitimate privacy measure, not an evasion.

What to do: Ask whether a lower clearing level can be configured for the assessment period, or request supplemental documentation that provides the stripped context. For classified environments (Level 3), accept that factor values are the maximum available evidence.

Major

No AI procedures witnessed

What it looks like: The organization deploys AI systems but has no witness anchors for AI procedures.

What it means: AI operations are not being witnessed. There is no cryptographic evidence of AI behavior.

What to do: Document this as a gap. The organization needs to integrate the witness SDK into their AI pipeline. Recommend a timeline for implementation and a follow-up assessment.

12. Glossary

Term	Definition
Clearing Level	Data minimization setting (0-3) that controls how much context is included in each anchor. Higher levels strip more information for privacy.
Compliance Passport	One-page HTML summary of an organization's compliance posture across all frameworks.
Factor A / B / C	Three numeric values in each anchor that capture the measurable aspects of a compliance event. Semantics vary by procedure.
Fingerprint	First 12 hex characters of a SHA-256 hash computed from the anchor's inputs. Used to verify integrity.
INHERITED	A verdict indicating the control is the responsibility of the infrastructure provider, not the deploying organization.
Merkle Rollup	Daily aggregation of all anchors into a single cryptographic root hash. Proves no anchors were added, removed, or modified after the rollup.
Namespace	A grouping of related UCT procedures (e.g., AI-INF for inference, AI-GRD for guardrails).
OSCAL	Open Security Controls Assessment Language. NIST standard for machine-readable compliance artifacts (SSP, POA&M, Assessment Results).
POA&M	Plan of Action and Milestones. Tracks open findings with remediation timelines. SWT3 auto-generates entries from FAIL verdicts.
Procedure	A specific, witnessable compliance event in the UCT Registry. Each procedure has a unique ID (e.g., AI-INF.1).
Revocation	Formal invalidation of a previously minted anchor. The original anchor remains in the ledger; a new AI-REV.1 anchor marks it as revoked.
Sovereign Score	Percentage of in-scope procedures with a PASS verdict. Used as a summary metric, not a certification.
SWT3	The Sovereign Witness Token v3 protocol. An open standard for cryptographic compliance evidence.
UCT	Universal Control Taxonomy. The catalog of all witnessable procedures in the SWT3 protocol.
Verdict	The deterministic outcome of a procedure evaluation: PASS, FAIL, or INHERITED.
Witness Anchor	A signed, timestamped, cryptographically fingerprinted record of a compliance event. The atomic unit of SWT3 evidence.

Assessor Evidence Matrix -- Detailed artifact-to-requirement mapping for EU AI Act, NIST 800-53, and CMMC
C3PAO Assessment Guide -- CMMC-specific deep dive with STIG provenance and assessment objectives
Notified Body One-Pager -- Executive summary for NB leadership
NB Pilot Scope -- 10-day, $10K evaluation engagement structure
SR 11-7 Overlay -- Financial services model risk deep dive
UCT Registry Reference -- Complete 204-procedure catalog with factor definitions
SWT3 Protocol Overview -- Technical architecture for engineering teams
Provider Outage Resilience -- How SWT3 maintains evidence during AI provider failures

Neutrality statement: TeNova Axiom is an independent evidence platform. It does not grant certifications, issue conformity assessments, or replace the professional judgment of assessors. Verdicts and scores are computed deterministically from machine-gathered evidence and are provided for informational purposes. The final authority on conformity, compliance, or risk acceptability rests with the designated assessment body.

EU AI Act Conformity

CMMC / NIST 800-53

SR 11-7 Model Risk

ISO 42001 / Multi-Framework

Contents

1. What is SWT3?

How it works

Traditional evidence vs. cryptographic evidence

2. Anatomy of a Witness Anchor

Factor semantics

Clearing levels

Fingerprint formula

3. The Assessment Workflow

Request the evidence package

Verify anchor integrity

Check evidence continuity

Examine verdicts by procedure

Validate factor semantics

Check for revocations

Form your assessment opinion

Decision tree

4. UCT Registry Quick Reference

Key AI namespaces for assessors

How to read a procedure entry

5. Evidence Artifacts Reference

6. EU AI Act Playbook

Article 9: Risk Management System

Article 11: Technical Documentation

Article 12: Record-Keeping

Article 14: Human Oversight

Article 15: Accuracy, Robustness, Cybersecurity

Article 50: AI-Generated Content

Article 62: Serious Incident Reporting

7. CMMC / NIST 800-53 Playbook

Where AI procedures fit in your assessment

OSCAL compatibility

8. SR 11-7 Playbook

9. ISO 42001 / Multi-Framework Playbook

The multi-framework value

Client recommendation

10. Verification Walkthrough

Browser verification (recommended for spot-checks)

Offline verification (for classified or air-gapped environments)

11. Common Assessment Findings

Gap in evidence timeline

FAIL verdict in the ledger

Revoked anchor (AI-REV.1)

INHERITED verdict

Clearing level mismatch

No AI procedures witnessed

12. Glossary

13. Related Guides