Home / Guides / Sampling Instructions
SWT3 Protocol

Assessor Sampling Instructions

5 queries to audit AI compliance evidence. What healthy looks like. What gaps look like.

Who this is for: Notified Body assessors (EU AI Act), C3PAOs (CMMC), ISSMs (NIST 800-53 / RMF), ISO 42001 certification auditors, bank examiners (SR 11-7), and internal audit teams reviewing SWT3 witness anchor evidence.

Critical Assessor Notice: Boundaries of Cryptographic Evidence

SWT3 witness anchors prove 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. Each regulatory framework retains its own assessment authority, methodology, and determination standards.

Contents

1. What to Request Before the Assessment 2. Why Sampling Matters 3. Query 1: Coverage Check 4. Query 2: Gap Detection 5. Query 3: Drift Detection 6. Query 4: Temporal Continuity 7. Query 5: Revocation Audit 8. What a Healthy Anchor Stream Looks Like 9. Red Flags Checklist 10. Sample Size Guidance 11. Export Instructions 12. How to Cite Verified Evidence 13. Related Guides

1. What to Request Before the Assessment

Before the on-site or remote assessment, request these artifacts from the client:

Pre-Assessment Artifact Request

2. Why Sampling Matters

Continuous monitoring produces thousands of anchors over an assessment period. An AI system reporting inference provenance hourly generates 2,160 anchors per quarter. You do not need to verify all of them. You need to verify the right ones.

These five queries are designed to surface the evidence patterns that matter most for compliance determination. Each query targets a specific assessment concern, tells you exactly how to run it against a CSV export, and explains what healthy and suspicious results look like.

CSV-first approach

Every query below is written for a spreadsheet (Excel, Google Sheets, LibreOffice Calc). Open the ledger CSV, apply the filters described, and read the results. No API access, no terminal, no software installation required. API equivalents are included in collapsible sections for technical assessors.

Factor Convention Note

Factor legends in this guide (e.g., "factor_b = observed drift magnitude") reflect the SWT3 SDK default conventions. Clients may customize factor usage in their implementation. Before relying on factor interpretations, ask the client to confirm their factor mapping matches the SDK defaults, or request their factor mapping document.

Methodology Boundary

This guide documents evidence format and suggested review techniques. It does not prescribe assessment methodology. Sample sizes, sufficiency determinations, and assessment conclusions remain the assessor's professional responsibility under their applicable accreditation and regulatory requirements.

Reading the CSV: Worked Example

The ledger CSV export contains one row per anchor. Here is what a typical excerpt looks like, with annotations showing what to look for:

#procedure_idverdictfactor_afactor_bfactor_ccreated_atAssessment Notes (assessor annotations, not in export)
1AI-INF.1PASS1102026-06-01 08:12Healthy -- normal inference
2AI-INF.1PASS1102026-06-01 09:15Healthy -- regular cadence
3AI-DRIFT.1PASSaccuracy0.030.102026-06-02 00:01Healthy -- drift (0.03) within threshold (0.10)
4AI-INF.1PASS1102026-06-15 14:22Red flag -- 13-day gap since row 2
5AI-DRIFT.1PASSaccuracy0.120.102026-06-16 00:01Red flag -- drift (0.12) exceeds threshold (0.10) but verdict is PASS
6AI-GRD.1FAILtoxicity0harmful_content2026-06-17 11:30Expected -- FAIL detected, check for remediation
7AI-GRD.1PASStoxicity1harmful_content2026-06-17 15:45Healthy -- FAIL remediated same day
8AI-FAIR.1PASSgender1.021.202026-06-18 09:00Healthy -- disparity (1.02) within threshold (1.20)

Key observations from this sample: Row 4 has a 13-day gap (Query 4 would catch this). Row 5 shows drift exceeding the threshold with a PASS verdict -- ask the client why the verdict is PASS when the threshold was exceeded (Query 3 would catch this). Row 6-7 shows a healthy FAIL-then-PASS remediation pattern (Query 2 would confirm this). The created_at column in this export uses ISO 8601 format -- some exports may use Unix epoch timestamps instead.

3. Query 1: Coverage Check

Query 1 of 5

Are all expected procedures producing evidence?

What this tells you: Whether continuous monitoring is active across all applicable procedures. Missing procedures indicate controls that are not being evaluated -- regardless of whether the organization claims they are implemented.

How to run it (CSV)

  1. Open the ledger CSV in your spreadsheet tool.
  2. Filter the created_at column to the last 90 days.
  3. Create a pivot table: rows = procedure_id, values = COUNT of rows.
  4. Compare the resulting procedure list against the client's declared in-scope procedures.
  5. Any procedure on the client's list but absent from the pivot table is a gap.
With API access (technical assessors)
GET /api/v1/ai-witness/export?days=90 Authorization: Bearer axm_... # Response includes procedure-level summary with anchor counts

Healthy

  • Every in-scope procedure has anchors
  • No gaps longer than 7 days for critical procedures (AI-INF.1, AI-GRD.1)
  • Anchor count is proportional to system activity (busy systems have more anchors)

Suspicious

  • Procedures with zero anchors despite being declared in-scope
  • Anchors only in the most recent week (audit-eve cramming)
  • Procedure count significantly lower than declared scope
Framework mapping: ISO 42001 Clause 9.1 (monitoring) | NIST CA-7 (continuous monitoring) | EU AI Act Art. 72 (post-market monitoring) | CMMC CA.L2-3.12.1 | SR 11-7 ongoing monitoring

Visual: Coverage Grid Example

A healthy deployment shows all expected procedures with anchor counts. Missing procedures (dashed red) are gaps requiring explanation.

847AI-INF.1
Inference
92AI-DRIFT.1
Drift
12AI-GOV.1
Policy
45AI-GRD.1
Guardrails
8AI-FAIR.1
Fairness
0AI-HITL.1
Gap
3AI-REV.1
Revocation
0AI-DATA.1
Gap

In this example, AI-HITL.1 (human oversight) and AI-DATA.1 (data provenance) have zero anchors despite being in scope. These are findings.

4. Query 2: Gap Detection

Query 2 of 5

Which controls are failing or unmonitored?

What this tells you: Identifies non-compliance and control gaps. FAIL verdicts are expected (they demonstrate honesty), but persistent FAILs without remediation indicate unresolved deficiencies.

How to run it (CSV)

  1. Filter the verdict column to show only FAIL rows.
  2. Sort by procedure_id, then by created_at (newest first).
  3. For each procedure with FAIL verdicts: check if a subsequent PASS exists. A FAIL followed by a PASS indicates remediation. A FAIL with no subsequent PASS indicates an open deficiency.
  4. Cross-reference open FAILs with the client's POA&M (Plan of Action and Milestones).
With API access (technical assessors)
GET /api/v1/ledger?verdict=FAIL&days=90 Authorization: Bearer axm_... # Returns all FAIL verdicts in the period

Healthy

  • FAIL anchors exist (the system detects and records failures)
  • Most FAILs are followed by a PASS within the POA&M remediation window
  • Remaining open FAILs are documented in the POA&M with milestones

Suspicious

  • Zero FAIL verdicts across all procedures (either perfect or not testing)
  • FAIL verdicts with no subsequent remediation and no POA&M entry
  • Same procedure alternating PASS/FAIL rapidly (unstable control)
Factor interpretation for gap analysis
When reviewing FAIL anchors, the factors tell you why the control failed. Example for AI-GRD.1 (guardrails): factor_a = guardrail type, factor_b = test result (0=failed), factor_c = blocked content category.

Visual: Healthy Remediation Flow

A FAIL verdict is not a problem -- it demonstrates the system is testing honestly. The concern is what happens after. This is the healthy pattern:

✗FAIL DetectedAI-GRD.1 Jun 17
→
🔧Corrective ActionSame day
→
✓PASS ConfirmedAI-GRD.1 Jun 17
→
📋POA&M ClosedDocumented

Red flag pattern: A FAIL with no subsequent PASS and no POA&M entry. This means the deficiency was detected but neither remediated nor documented.

Framework mapping: ISO 42001 Clause 10.1 (nonconformity) | NIST CA-2 (assessment) | EU AI Act Art. 9(9) (risk management updates) | CMMC CA.L2-3.12.3 | SR 11-7 deficiency tracking

5. Query 3: Drift Detection

Query 3 of 5

Is the AI model drifting beyond acceptable thresholds?

What this tells you: Whether the AI model's behavior has changed beyond the organization's configured thresholds. Drift is normal -- undetected or unaddressed drift is the risk.

How to run it (CSV)

  1. Filter procedure_id to AI-DRIFT.1.
  2. Compare factor_b (observed drift magnitude) against factor_c (configured threshold) for each row.
  3. Flag any rows where the observed drift exceeds the threshold (factor_b > factor_c).
  4. Check whether threshold-exceeding rows triggered corrective action (look for subsequent AI-MDL.2 anchors indicating model update).
Factor legend for AI-DRIFT.1
factor_a = drift metric identifier (e.g., "accuracy", "output_distribution") | factor_b = observed drift magnitude (numeric) | factor_c = configured threshold (numeric). When factor_b > factor_c, drift has exceeded the acceptable limit.
With API access (technical assessors)
GET /api/v1/ledger?procedure=AI-DRIFT.1&days=90 Authorization: Bearer axm_... # Review factor_b vs factor_c in response rows

Healthy

  • Regular AI-DRIFT.1 anchors (weekly or more frequent)
  • Observed drift (factor_b) generally within ~10% of threshold (factor_c)
  • Occasional threshold exceedances followed by corrective action

Suspicious

  • No AI-DRIFT.1 anchors despite active model deployment
  • Observed drift consistently exceeding threshold with PASS verdicts (threshold may be set too loosely)
  • Identical drift values across all checks (synthetic or copy-paste data)

Visual: Drift Over Time

Each bar represents one AI-DRIFT.1 anchor. The dashed line is the configured threshold. Bars above the line are threshold exceedances.

AI-DRIFT.1 -- accuracy metric (90-day view)

threshold (0.10)
Week 1Week 5Week 9Week 13

Reading this chart: Green bars = drift within threshold. Amber = approaching threshold. Red = exceeded threshold. The two red bars in weeks 9-10 should be followed by an AI-MDL.2 anchor (model update). If they are not, the organization detected drift but did not act on it.

Framework mapping: ISO 42001 A.8.3 (performance management) | NIST MEASURE 2.5 (AI trustworthiness) | EU AI Act Art. 9(2)(b) (continuous risk assessment) | SR 11-7 ongoing monitoring

6. Query 4: Temporal Continuity

Query 4 of 5

Is monitoring truly continuous, or was evidence generated just before the audit?

What this tells you: Whether the organization has been continuously monitoring throughout the assessment period, or whether evidence was generated in a burst shortly before the scheduled audit.

How to run it (CSV)

  1. Filter procedure_id to a high-frequency procedure such as AI-INF.1 (inference provenance).
  2. Sort by created_at (oldest first).
  3. In a new column (e.g., column G), compute the time gap between consecutive rows. If created_at is in column F, enter =F3-F2 in cell G3 and drag down. Format column G as hours or days. If timestamps are Unix epoch numbers, use =(F3-F2)/86400 to get days.
  4. Scan column G for gaps: any value that exceeds the organization's stated monitoring frequency. For a system monitored hourly, a gap >24 hours warrants investigation.
  5. Check the distribution: scroll through the date column visually. Are anchors evenly spread across the period, or clustered in the final weeks before the audit?
With API access (technical assessors)
GET /api/v1/ledger?procedure=AI-INF.1&days=90&sort=created_at Authorization: Bearer axm_... # Compute timestamp deltas between consecutive entries

Healthy

  • Regular intervals matching the organization's stated frequency
  • Consistent cadence over the full 90+ day period
  • Minor gaps during planned maintenance windows (documented)

Suspicious

  • Large gaps (weeks) followed by dense clusters before the audit date
  • No anchors on weekends/holidays for a system that operates 24/7
  • Anchor timestamps all within a narrow window (bulk retroactive generation)

Visual: Healthy vs Suspicious Temporal Distribution

Each green tick represents one anchor. Compare the two patterns below:

Healthy
Suspicious
Day 1Day 30Day 60Day 90 (audit)

Top row: Anchors evenly distributed across the 90-day period. This is continuous monitoring. Bottom row: One anchor early, then a large gap (red hatching), then a dense cluster of anchors just before the audit date. This suggests audit-eve cramming.

Framework mapping: ISO 42001 Clause 9.1 (continuous monitoring) | NIST CA-7 (continuous monitoring strategy) | EU AI Act Art. 12(1) (automatic logging throughout lifecycle) | CMMC CA.L2-3.12.1

7. Query 5: Revocation Audit

Query 5 of 5

Are retired models properly decommissioned?

What this tells you: Whether the organization has a functioning model retirement process. When a model is replaced or recalled, an AI-REV.1 anchor documents the revocation with a reason code. Models should stop producing new anchors after revocation.

How to run it (CSV)

  1. Filter procedure_id to AI-REV.1.
  2. Review the observations or evidence_summary column for revocation reason codes.
  3. For each revoked model: verify that no new AI-INF.1 anchors appear for that model after the revocation date.
  4. Check that the reason code is specific (not "unspecified").
Factor legend for AI-REV.1
factor_a = revoked anchor fingerprint | factor_b = reason code (0=unspecified, 1=model_recall, 2=policy_violation, 3=data_contamination, 4=consent_withdrawal, 5=regulatory_order, 6=error_correction) | factor_c = authority identifier
With API access (technical assessors)
GET /api/v1/ledger?procedure=AI-REV.1 Authorization: Bearer axm_... # Cross-reference with AI-INF.1 anchors for revoked models

Healthy

  • Revocations exist and correspond to model version changes
  • Specific reason codes (1-6) are used, not "unspecified" (0)
  • No new inference anchors for revoked models after revocation date

Suspicious

  • No revocations despite multiple model version changes (AI-MDL.2 anchors)
  • All revocations use reason code 0 ("unspecified") -- lacks governance rigor
  • New inference anchors appearing after revocation (revoked model still running)
Framework mapping: ISO 42001 A.8.5 (system retirement) | NIST CM-8(1) (component inventory updates) | EU AI Act Art. 72(3) (post-market modification) | SR 11-7 model lifecycle

8. What a Healthy Anchor Stream Looks Like

CharacteristicHealthy PatternConcerning Pattern
Frequency Matches the system type: real-time (financial/inference) produces hourly/per-request anchors; governance reviews produce daily/weekly anchors Erratic frequency or sudden density changes unrelated to system activity
Coverage All declared in-scope procedures have anchors; no silent gaps Missing procedures, or procedures that appear and disappear
Verdict distribution Majority PASS, some FAIL (honesty signal), FAILs followed by remediation within POA&M window 100% PASS (unrealistic perfection), or persistent FAIL without remediation
Temporal pattern Consistent cadence over full assessment period; minor gaps during documented maintenance Clusters before audit dates; large unexplained gaps; weekend blackouts for 24/7 systems
Factor variety Factor values vary naturally (different models, different metrics, different reviewers) Identical factor values across all anchors (copy-paste evidence)
Evidence detail Factors provide enough operational context for the assessor to evaluate substance Evidence detail is minimized for systems that do not warrant it -- ask the client why operational context is restricted

9. Red Flags Checklist

Print this page and check each item during your evidence review. Any checked item warrants further investigation -- it does not automatically indicate non-compliance, but it requires explanation from the client.

Evidence Red Flags

10. Sample Size Guidance

For each sample selected, independently verify the anchor fingerprint using the 5-second verification procedure. Do not rely solely on the client's verification -- perform at least a subset independently.

The table below reflects common practice observed across early SWT3 assessments. Your accreditation body, assessment methodology, or regulatory authority may prescribe different sample sizes. Adjust accordingly.

Assessment TypeCommon PracticeVerification Method
ISO 42001 Stage 2 certification 10% of anchors or 100, whichever is greater Independent fingerprint recomputation for all sampled anchors
ISO 42001 surveillance audit 5% of anchors or 50, whichever is greater Independent fingerprint recomputation for sampled anchors
CMMC Level 2 assessment 10% of anchors or 100, whichever is greater Recompute fingerprints; verify against CMMC practice mapping
EU AI Act conformity assessment All anchors for high-risk procedures (AI-INF.1, AI-FAIR.1, AI-HITL.1); 10% for others Full recomputation for high-risk; sampling for standard-risk
Bank regulatory examination (MRIA models) All anchors for models rated MRIA (Most Require Immediate Attention) Full recomputation; cross-reference with model inventory
Bank regulatory examination (MRA models) 10% of anchors per MRA model Sampling with independent recomputation
Spot check / internal audit 5-10 randomly selected anchors across procedures Web verifier or terminal verification
Random selection matters.

Do not let the client choose which anchors to verify. Select your sample randomly from the ledger export -- sort by a column unrelated to compliance (e.g., alphabetical by fingerprint), then take every Nth row. This prevents the client from pre-selecting passing anchors.

11. Export Instructions

Three ways to obtain the ledger data for your review:

MethodHowWhat You Get
CSV Export Ledger page in the dashboard -- click "Export CSV" button. Available to all authenticated users. Full ledger with procedure_id, verdict, factors, timestamps, evidence summaries. Opens in Excel/Sheets.
JSON Export GET /api/v1/ai-witness/export with Bearer token. Supports ?days=90 and ?format=json parameters. Structured JSON with procedure-level summaries and individual anchor records.
Compliance Passport GET /api/v1/passport/export -- available as HTML (Pro+), HMAC-signed JSON (Pro+), or W3C Verifiable Credential (Enclave+). Framework-mapped compliance summary with integrity signatures. The VC format is self-verifiable using the issuer's public DID document.

The assessor should always independently verify a subset of anchors from the export, not just review the export contents. The export provides the data; independent verification confirms its integrity.

12. How to Cite Verified Evidence in Your Report

When referencing SWT3 anchor evidence in your assessment report, use a consistent citation format. The following template covers the key elements:

Sample citation

"The assessor independently verified SWT3 Witness Anchor [full token] using SHA-256 fingerprint recomputation (FIPS 180-4). The anchor confirms that procedure [procedure ID] was evaluated on [human-readable date] with verdict [PASS/FAIL]. Factor values: [factor_a description] = [value], [factor_b description] = [value], [factor_c description] = [value]. Verification method: [web verifier / terminal / PowerShell]. Result: fingerprint match confirmed -- evidence integrity verified."

For sampling summary citations:

Sample summary citation

"The assessor reviewed [N] SWT3 witness anchors covering the period [start date] to [end date]. [X] of [Y] sampled anchors were independently verified via fingerprint recomputation. Coverage: [N] procedures produced evidence. Gaps identified: [list or 'none']. Red flags: [list or 'none']. Assessment conclusion: [assessor's determination]."

Assessor Resources