When you instrument your AI client with the SWT3 SDK, every inference generates a witness anchor. This anchor is a single cryptographic artifact with two audiences.
"My system is instrumented. Evidence is being generated automatically. Every inference, every tool call, every access decision is recorded with a tamper-evident fingerprint."
"I have a tamper-evident record I can verify independently without trusting the developer. The SHA-256 fingerprint either matches the evidence factors or it does not."
The anchor does not care who reads it. The SHA-256 fingerprint either matches the evidence factors or it does not. This is what makes SWT3 a protocol, not a platform. Verification requires nothing but the hash function.
Here is what happens, step by step, when an auditor evaluates your SWT3 evidence.
Your organization generates an audit share link. The auditor opens it in any browser. No account, no installation, no vendor relationship required.
The portal displays a table of all instrumented procedures. Each row shows the procedure ID, the title, the verdict (PASS, FAIL, or INHERITED), the last witnessed timestamp, and a verify link.
Hovering over any procedure reveals the three evidence factors: the standard being evaluated, the evidence collected, and the context of the evaluation. Framework badges show which regulations this procedure satisfies.
Clicking "Verify" opens the public verifier at /verify. The auditor enters the anchor's fingerprint. The verifier re-derives the SHA-256 hash from the factors and confirms authenticity. No server, no API key, no trust assumption.
The auditor navigates to the assessment checklist page, selects their framework, and generates a printable checklist. Every procedure you instrumented appears as a row they can check off.
The auditor now has verified anchors, a signed checklist, and a framework-specific walkthrough guide. This is stronger evidence than any attestation letter because it is independently verifiable and tamper-evident.
The following table shows how your SDK instrumentation maps to the evidence your auditor verifies and the regulatory requirements it satisfies.
| What You Instrument | What Your Auditor Verifies | EU AI Act | NIST AI RMF |
|---|---|---|---|
| Client wrapping | AI-INF.1 Inference witnessed with timestamp and model ID | Art. 12(1) | GOVERN 2.1 |
| RAG provenance | AI-RAG.1 Document hashes and retrieval metadata | Art. 13 | MAP 2.3 |
| Tool witnessing | AI-TOOL.1 Tool call chain with execution timestamps | Art. 12(1) | GOVERN 1.7 |
| Agent identity | AI-ID.1 Agent fingerprint across all anchors | Art. 12(1) | MAP 1.1 |
| Access control gate | AI-ACC.1 Authorization decision per inference | Art. 9(4)(c) | MANAGE 2.4 |
| Anchor revocation | AI-REV.1 Revocation with reason code linked to original | Art. 14(4)(d) | MANAGE 2.4 |
| Model metadata | AI-MDL.1/5/6 Version, weights hash, adapter stack | Art. 11 | GOVERN 1.2 |
| Drift detection | AI-DRIFT.1 Model output deviation from baseline | Art. 9(2)(b) | MEASURE 2.6 |
View the complete mapping for any framework at the Assessment Mapping page.
Every SWT3 Witness Anchor is a single string with seven segments. Each segment carries specific meaning for both developer and auditor.
Your SDK call produced this anchor. The fingerprint (last 12 hex characters) is derived from SHA-256 of the evidence factors you provided: the standard evaluated, the evidence collected, and the context of the evaluation.
The auditor enters this anchor at /verify. The verifier re-derives the fingerprint from the same factors. If the derived fingerprint matches the anchor, the evidence is authentic and has not been modified since it was witnessed.
Your auditor follows a framework-specific walkthrough guide that maps these procedures to their regulatory requirements. Each guide shows the auditor exactly what to check, what a PASS verdict means, and what common findings look like.