A 4-step methodology for evaluating governance evidence produced by the SWT3 protocol. Positions SWT3 as the first stop in the assessment -- not the entire assessment.
Who this is for: C3PAOs conducting CMMC Level 2 assessments, EU AI Act Notified Bodies performing conformity assessment, 3PAOs conducting FedRAMP assessments, ISSMs managing RMF authorization, ISO 42001 certification body auditors, bank examiners evaluating SR 11-7 model risk compliance, and any assessor encountering SWT3 witness anchors for the first time.
SWT3 witness anchors provide mathematical proof that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. No over-reliance on automated evidence is warranted or intended. Each regulatory framework retains its own assessment authority, methodology, and determination standards.
SWT3 governance evidence is the starting point of an assessment, not its conclusion. The protocol provides the cryptographic baseline of operational facts. The assessor then applies professional judgment, regulatory expertise, and substantive testing to reach a determination.
Verify the SWT3 anchor fingerprint using SHA-256. This confirms that the recorded operational event occurred at the stated time without subsequent tampering.
What this proves: An operational event happened, with specific measured values (factor_a, factor_b, factor_c), at a specific epoch timestamp, and the record has not been altered since minting.
What this does not prove: That the governance policy behind the event was adequate. That the risk acceptance was sound. That the personnel involved were competent. That the organization's governance structure is well-designed. These are the assessor's domain.
Verification can be performed independently using any SHA-256 tool. No API key, account, or network connection to the SWT3 platform is required. See the Assessor Onboarding Kit for a step-by-step verification walkthrough.
SWT3 provides four layers of temporal proof, three of which are independently verifiable without trusting the platform operator:
SWT3:LEAF: / SWT3:NODE: prefixes) computed at 00:01 UTC. A single root hash covers all anchors for a tenant on a given day. Inclusion proofs are available via the Merkle Proof API.To verify temporal integrity: confirm the anchor's fingerprint appears in the daily Merkle tree (Layer 2), then verify the Merkle root's RFC 3161 timestamp token against the TSA certificate (Layer 3). This proves the anchor existed at or before the TSA-signed time, independently of the SWT3 platform.
Map the UCT procedure identified in the anchor to the regulatory requirement applicable to your assessment. The Universal Control Taxonomy (UCT) provides a shared procedural vocabulary that assessors can reference across jurisdictions.
For example, an anchor for procedure AI-HITL.1 (Human Review Capability) is relevant to EU AI Act Article 14 (Human Oversight), NIST SP 800-53 SI-4 (System Monitoring), and CMMC assessment objectives for human-in-the-loop validation.
The UCT Registry provides searchable procedure-to-framework mappings. The Assessor Evidence Matrix provides per-procedure coverage classification.
This is where the assessor leaves the SWT3 portal and verifies physical, organizational, and qualitative evidence in the assessed organization's own systems.
For requirements where the SWT3 anchor provides Partial or Pointer coverage, the assessor must inspect external records to complete the assessment objective. Examples:
Section 3 of this guide provides detailed pivot guidance for every governance procedure, specifying exactly what the assessor verifies next and where to look.
After completing the assessment, the organization can witness the assessment event itself back into the SWT3 evidence chain using AI-ASSESS.1 (Champion-Challenger Assessment Witnessing). This creates an immutable record that an assessment was conducted, by whom, covering what scope, with what declared outcome.
This closes the evidence loop. Future assessors reviewing the evidence chain can see that a prior assessment occurred, reducing redundant evidence gathering for continuous monitoring (CA-7) and POA&M closeout assessments.
The assessment record does not contain the assessor's findings, scoring, or determination. It witnesses the fact that an assessment event occurred. The assessment report itself remains in the assessor's and organization's records.
Every SWT3 procedure has an evidence boundary -- the explicit point where the protocol's cryptographic evidence ends and the assessor's substantive testing begins. Three classifications describe the role SWT3 evidence plays for a given requirement:
| Classification | Definition | Assessor Action |
|---|---|---|
| Full | The SWT3 anchor alone contains sufficient evidence to satisfy the assessment objective. The anchor records the operational control's measured state with factor values that directly demonstrate compliance. Example: AI-AUDIT.1 (Audit Log Integrity) -- the anchor records entries checked, integrity status, and verification timestamp. |
Verify anchor authenticity. Validate factor values against expected thresholds. No supplementary evidence required. |
| Partial | The SWT3 anchor proves that an operational control was active and records measured values, but the assessment objective also requires qualitative documentation or policy context that the anchor does not contain. Example: AI-HITL.1 (Human Review Capability) -- the anchor proves a human review event occurred, but the assessor must verify the reviewer's qualifications and the adequacy of the review process. |
Verify anchor authenticity. Then inspect supplementary documentation (policies, training records, process descriptions) to complete the objective. |
| Pointer | The SWT3 anchor records that a governance event occurred -- a decision was made, a policy was approved, an authority was delegated -- but the substance of that decision must be verified in the organization's own governance records. The anchor is an immutable index to where the real evidence lives. Example: AI-GOV.4 (Governance Policy Update) -- the anchor records that a policy was updated from version N to version N+1 with a content hash, but the assessor must review the actual policy document. |
Verify anchor authenticity. Use the recorded metadata (version numbers, content hashes, authority identifiers) as an index to locate and inspect the actual governance records. |
The evidence boundary taxonomy is a documentation concept. In the SWT3 assessment objectives database, POINTER maps to the existing PARTIAL coverage level. The distinction between PARTIAL and POINTER helps assessors understand whether they need additional technical evidence (PARTIAL) or additional governance evidence (POINTER).
This section provides the core operational reference for assessors. For each governance procedure, the table specifies what SWT3 proves, where the evidence boundary is, and exactly what the assessor verifies next.
| Procedure | What SWT3 Proves | Evidence Boundary | Assessor Verifies Next | Where to Look |
|---|---|---|---|---|
AI-GOV.1Governance Framework |
A governance framework was active with N controls defined, M controls active, at a specific version | Pointer | Review the governance framework document. Confirm controls are appropriate, risk-based, and approved by authorized governance body. | Governance policy repository, board minutes, risk committee records |
AI-GOV.2Governance Review |
Governance reviews were scheduled (N) and completed (M) within the review period | Pointer | Review meeting minutes for completed reviews. Confirm reviews were substantive (not rubber-stamp). Verify attendee authority. | Calendar records, meeting minutes, review sign-off sheets |
AI-GOV.4Policy Update |
Policy was updated from version N to version N+1 with a content hash delta | Pointer | Retrieve the policy document matching the content hash. Confirm the change was approved through the organization's change control process. | Policy document management system, change advisory board records |
AI-GOV.5Accountability |
N accountability roles were assigned, M were acknowledged by assignees | Pointer | Verify that role assignments correspond to real personnel. Confirm acknowledgments are signed. Check that assigned roles have appropriate authority. | HR system, role assignment records, signed acknowledgment forms |
AI-GOV.6Escalation Paths |
N escalation paths were defined, M were tested, with last test date recorded | Pointer | Review escalation path documentation. Verify test results. Confirm paths reach appropriate authority levels. | Incident response plans, escalation test records, after-action reports |
| Procedure | What SWT3 Proves | Evidence Boundary | Assessor Verifies Next | Where to Look |
|---|---|---|---|---|
AI-METAGOV.1Governance Config |
Governance rules were active at a specific version with a content hash | Partial | Verify the governance rules are appropriate for the deployment context. Confirm the configuration matches documented policy. | Configuration management database, policy repository |
AI-METAGOV.2Layer Registration |
A governance layer was registered at a specific stack position with a configuration hash | Full | Verify anchor authenticity. The registration event itself is the evidence. | N/A -- anchor is self-sufficient |
AI-METAGOV.3Policy Downgrade |
A policy version decreased (downgrade detected). Records previous and current version with content hash. | Full | Verify the downgrade was intentional. If unintentional, escalate as a finding. | Change management records, approval for version rollback |
AI-METAGOV.5Governance Change Auth |
A governance change was authorized by a specific operator with credential hash, covering a defined scope and permission level | Pointer | Verify the operator had authority to authorize changes at the recorded permission level. Cross-reference the credential hash with the Identity Provider. | Identity Provider (IdP), role-based access control records, authority matrix |
AI-METAGOV.6Emergency Override |
An emergency override was invoked with a reason code, review window (hours), and operator identity | Pointer | Verify the override was justified. Confirm review was completed within the declared window. Check that the operator had emergency authority. | Incident records, emergency authorization matrix, post-incident review documentation |
AI-METAGOV.7Governance Sync |
Policy divergence detected between local and remote governance configurations with divergence type classification | Partial | Verify the divergence was resolved or accepted. Confirm federation governance agreements are in place. | Federation agreements, policy synchronization logs |
| Procedure | What SWT3 Proves | Evidence Boundary | Assessor Verifies Next | Where to Look |
|---|---|---|---|---|
AI-HITL.1Human Review |
A human review event was triggered and recorded prior to or during inference. Records reviewer identity method and override decision. | Partial | Verify the reviewer was a real human (not an automated script). Confirm the reviewer had appropriate expertise and authority for the decision context. | Identity Provider session logs, HR role records, training completion records |
AI-HITL.2Override Tracking |
A human override of an AI decision occurred. Records whether override was applied and the rationale classification. | Partial | Review override frequency and patterns. Assess whether overrides indicate systemic model issues. Verify rationale adequacy. | Override log, model performance reports, risk assessment updates |
AI-HITL.3Reviewer Identity |
The overseer's identity was cryptographically bound to the review event. Records identity method code and verification status. | Partial | Cross-reference the identity binding with the organization's IdP. For regulated industries: verify the individual holds required credentials (e.g., FCA Senior Management Function, CMMC Certified Assessor designation). | Identity Provider, professional licensing databases, regulatory registration systems |
| Procedure | What SWT3 Proves | Evidence Boundary | Assessor Verifies Next | Where to Look |
|---|---|---|---|---|
AI-DEL.1Delegation Tree |
Authority was delegated from a specific delegator to a delegatee with defined scope and depth. Records scope hash and delegation chain. | Pointer | Verify the delegator had authority to delegate. Confirm the scope was appropriate (not over-broad). Check for circular or conflicting delegations. Validate that the delegation is consistent with organizational authorization policies. | Authorization matrix, organizational chart, access control policy, delegation approval records |
| Procedure | What SWT3 Proves | Evidence Boundary | Assessor Verifies Next | Where to Look |
|---|---|---|---|---|
AI-AUDIT.1Audit Log Integrity |
Audit log entries were checked for integrity. Records entries examined, integrity verification result, and timestamp. | Full | Verify anchor authenticity. The integrity check result is the evidence. Optionally spot-check individual log entries to validate the integrity mechanism. | N/A for the anchor itself; audit log system for spot checks |
AI-AUDIT.2External Timestamp |
An external RFC 3161 timestamp was obtained from a Timestamping Authority, providing independent temporal attestation. | Full | Verify the TSA is accredited and trusted. Validate the timestamp token against the TSA's public certificate. | TSA certificate chain, RFC 3161 timestamp token |
| Procedure | What SWT3 Proves | Evidence Boundary | Assessor Verifies Next | Where to Look |
|---|---|---|---|---|
AI-CONSENT.1Data Subject Consent |
Consent was collected from N subjects under a specific legal basis type. Records whether withdrawal mechanism is available. | Pointer | Review consent forms and collection mechanism. Verify legal basis is appropriate for the jurisdiction. Confirm withdrawal mechanism is functional and accessible. | Consent management platform, privacy notices, DPIA records |
AI-ASSESS.1Assessment Record |
An assessment event occurred (champion-challenger evaluation or formal audit). Records assessment type, scope, and outcome declaration. | Pointer | Retrieve the full assessment report. Verify the assessment was conducted by qualified personnel using an appropriate methodology. | Assessment report archive, assessor credentials, assessment methodology documentation |
AI-EMRG.1Emergency Override Lifecycle |
An emergency override lifecycle was initiated, reviewed, and closed. Records lifecycle stage progression and review status. | Pointer | Verify each lifecycle stage was completed. Confirm the emergency was genuine. Review post-incident analysis for lessons learned and corrective actions. | Incident management system, post-incident review records, corrective action tracker |
The CMMC Assessment Guide (v2.13, September 2024) defines the assessment methodology based on NIST SP 800-171A. This section maps SWT3 evidence to the CMMC framework to help C3PAOs understand exactly how witness anchors integrate into their existing assessment process.
CMMC defines four categories of assessment objects. SWT3 evidence covers some but not all:
| Assessment Object | CMMC Definition | SWT3 Coverage | Assessor Responsibility |
|---|---|---|---|
| Specifications | Document-based artifacts: policies, procedures, security plans, functional specs, architectural designs | Pointer at best. SWT3 can record that a policy exists and its version/hash, but cannot attest to policy content, adequacy, or approval. | Full responsibility. Examine all specification documents independently. SWT3 version hashes can confirm you are reviewing the correct document version. |
| Mechanisms | Hardware, software, or firmware safeguards employed within a system | Full or Partial. SWT3 anchors directly prove that technical controls (mechanisms) were operating at a specific time with measured values. | Verify anchor authenticity. Validate factor values indicate the mechanism was functioning correctly. Spot-check by independently testing the mechanism where feasible. |
| Activities | Protection-related actions supporting a system that involve people | Pointer. SWT3 can record that an activity occurred (review, override, authorization) but cannot verify the quality or thoroughness of the activity. | Use the anchor as evidence that the activity was performed. Then verify the activity was performed competently and in accordance with organizational procedures. |
| Individuals | People applying the specifications, mechanisms, or activities | None. SWT3 does not assess personnel competence, qualifications, or awareness. | Full responsibility. Conduct interviews per NIST SP 800-171A. No SWT3 evidence applies. |
CMMC uses three assessment methods from NIST SP 800-171A. SWT3 evidence maps to one of them:
| Method | CMMC Definition | SWT3 Role |
|---|---|---|
| Test | Exercising assessment objects under specified conditions to compare actual with expected behavior | Primary. SWT3 anchors are the result of automated testing -- controls are exercised and measured values are recorded. Anchors serve as TEST method evidence that can supplement or accelerate the assessor's own testing. |
| Examine | Reviewing, inspecting, observing, studying, or analyzing assessment objects (specifications, mechanisms, activities) | None. Document review, policy analysis, and observational assessment are fully the assessor's domain. SWT3 anchors may point to documents worth examining but do not perform the examination. |
| Interview | Holding discussions with individuals to facilitate understanding, achieve clarification, or obtain evidence | None. Personnel interviews are fully the assessor's domain. SWT3 records operational events, not personnel testimony. |
The C3PAO retains sole authority over MET/NOT MET/NOT APPLICABLE determinations per the CMMC Assessment Guide v2.13 and 32 CFR 170.24. SWT3 evidence may inform the assessor's determination but does not predetermine it. Per NIST SP 800-171A: "Organizations [Certified Assessors] have the flexibility to determine the level of effort needed and the assurance required for an assessment."
The CMMC Assessment Guide defines three possible findings: MET, NOT MET, and NOT APPLICABLE. SWT3 evidence contributes to the assessor's determination as follows:
A single SWT3 anchor records an operational fact. Different jurisdictions interpret that fact differently based on their regulatory frameworks. The UCT provides a shared procedural vocabulary that allows a single witnessed event to be referenced by multiple frameworks.
The matrix below shows representative examples. The full crosswalk is available in the UCT Registry.
| Procedure | Operational Fact | EU AI Act | NIST 800-53 | CMMC L2 | Assessor Action |
|---|---|---|---|---|---|
AI-HITL.1 |
Human review event occurred prior to output release | Art. 14(1): Natural person oversight prior to release | SI-4: System Monitoring | SI.L2-3.14.6: Monitor communications | EU: Verify 4-eyes rule. US: Verify monitoring coverage. Both: Confirm reviewer identity in IdP. |
AI-GOV.1 |
Governance framework active with N/M controls operational | Art. 9(1): Risk management system | PL-1: Policy and Procedures | CA.L2-3.12.4: System Security Plan | EU: Confirm risk tiers. US: Examine SSP. Both: Review framework document quality. |
AI-ACC.1 |
Agent access request with scopes requested vs. scopes granted | Art. 9(4)(c): Risk mitigation via access controls | AC-6: Least Privilege | AC.L2-3.1.5: Least Privilege | EU: Verify scope minimization. US: Verify least privilege enforcement. Both: Review scope justification. |
AI-DRIFT.1 |
Model drift measured: baseline vs. current score with response action | Art. 15(1): Continuous monitoring against statutory thresholds | CA-7: Continuous Monitoring | CA.L2-3.12.3: Security Control Monitoring | EU: Confirm drift thresholds per Art. 15. US: Confirm monitoring cadence. Both: Review response adequacy. |
AI-DEL.1 |
Authority delegated with scope, depth, and delegator identity | Art. 28(2): Deployer obligations in delegation | AC-2: Account Management | AC.L2-3.1.1: Authorized Access | EU: Verify deployer compliance. US: Verify authorized delegation. Both: Check delegation scope bounds. |
AI-CONSENT.1 |
Consent collected from N subjects under legal basis type with withdrawal available | Art. 10(5): Data quality and consent | AP-2: Purpose Specification (NIST Privacy) | N/A (not CUI-scoped) | EU: Verify GDPR-compliant consent mechanism. US: Verify purpose limitation. Review withdrawal functionality. |
Key principle: One anchor. One operational fact. Multiple regulatory interpretations. The assessor determines sufficiency in each context.
A C3PAO is assessing AC.L2-3.1.1 (Authorized Access Control). The OSC uses an AI agent with SWT3 witnessing.
Step 1 -- Verify: The C3PAO locates an AI-ACC.1 anchor in the evidence package: SWT3-E-VULTR-AI-ACC1-PASS-1786500000-a1b2c3d4e5f6. They verify the fingerprint using SHA-256. It matches. The anchor is authentic.
Step 2 -- Map: The UCT crosswalk shows AI-ACC.1 maps to CMMC AC.L2-3.1.1 assessment objectives [a] through [d]. Coverage is Partial -- the anchor proves the access control mechanism was enforced, but EXAMINE and INTERVIEW objectives remain.
Step 3 -- Pivot: The C3PAO examines the access control policy document (EXAMINE). They interview the system administrator about how access types are defined (INTERVIEW). The SWT3 anchor confirmed the mechanism works; the C3PAO confirmed the policy is adequate and the admin understands the requirements.
Step 4 -- Record: The OSC witnesses the assessment event via AI-ASSESS.1, recording that the C3PAO assessment covered AC.L2-3.1.1 on this date.
Determination: The C3PAO marks AC.L2-3.1.1 as MET based on combined TEST evidence (SWT3 anchor), EXAMINE evidence (policy review), and INTERVIEW evidence (admin discussion).
A Notified Body is performing conformity assessment of a high-risk AI system. Article 14 requires human oversight measures.
Step 1 -- Verify: The NB verifies an AI-HITL.1 anchor proving a human review event occurred before a classification decision was released. Fingerprint verified.
Step 2 -- Map: UCT crosswalk maps AI-HITL.1 to Article 14(1) and 14(4). Coverage is Partial -- the anchor proves oversight was operational, but the NB must assess whether the oversight measures are "appropriate to the circumstances."
Step 3 -- Pivot: The NB reviews the human oversight procedure documentation (instructions for use per Article 13). They verify the reviewer held appropriate qualifications by cross-referencing the agent_id in the anchor's CJT metadata with the organization's HR system. They assess whether the level of human oversight is proportionate to the risk classification.
Step 4 -- Record: The assessment event is witnessed. The conformity assessment report references the SWT3 anchor as supporting evidence.
Determination: The NB determines Article 14 conformity based on the combination of SWT3 evidence (operational proof of oversight mechanism), documentation review (procedures and qualifications), and proportionality assessment (professional judgment).
A certification body auditor is conducting a Stage 2 audit for ISO/IEC 42001 certification. Clause 6.1 requires the organization to determine risks and opportunities related to AI.
Step 1 -- Verify: The auditor verifies an AI-GOV.1 anchor showing a governance framework was active with 24 controls defined and 22 controls active.
Step 2 -- Map: UCT crosswalk maps AI-GOV.1 to Clause 6.1.1 (General) and Annex A.2 (AI risk management). Coverage is Pointer -- the anchor proves the framework exists and is operational, but the auditor must assess whether the framework adequately addresses Clause 6.1 requirements.
Step 3 -- Pivot: The auditor reviews the AI risk assessment documentation. They verify that the 2 inactive controls (24 defined, 22 active) are documented with justification. They interview the AI management system representative about how risks are identified and treated.
Determination: The auditor records the finding based on combined evidence. The 2 inactive controls may be a minor nonconformity if unjustified, or acceptable if documented as planned risks.
A bank examiner is evaluating model risk management under OCC SR 11-7. Effective challenge requires that model outputs be reviewed by qualified personnel who can question assumptions.
Step 1 -- Verify: The examiner verifies an AI-HITL.3 anchor showing overseer identity was cryptographically bound to a review event with identity method code indicating strong authentication.
Step 2 -- Map: UCT crosswalk maps AI-HITL.3 to SR 11-7 Section V (Model Validation -- Effective Challenge). Coverage is Partial -- the anchor proves a reviewer was identified and authenticated, but effective challenge requires the reviewer to be independent and technically competent.
Step 3 -- Pivot: The examiner verifies the reviewer's independence (not the model developer). Reviews the reviewer's qualifications and model risk training records. Assesses whether the review was substantive (did the reviewer challenge assumptions, or merely approve?).
Determination: The examiner evaluates effective challenge based on reviewer independence, competence, and the substantive nature of the review -- none of which are captured in the SWT3 anchor.