How to Add Cryptographic Compliance Evidence to Any AI Application

A pattern catalog for developers and engineering leads. No code here, just the menu of what is possible and what each pattern proves.

You have an AI application in production or development. This guide shows which SWT3 capabilities generate evidence for which compliance requirements, so you can choose what to instrument based on what your auditor needs to verify.

SWT3 is an industry-agnostic cryptographic witness protocol. These patterns work with any AI provider, any framework, any deployment model. The SDK is published on PyPI and npm under Apache 2.0. Nothing here is vendor-specific. Every pattern produces tamper-evident evidence that satisfies multiple regulatory frameworks simultaneously.

1. One SDK, Any Stack

SWT3 works as a transparent overlay on your existing AI client. It supports OpenAI, Anthropic, AWS Bedrock, LiteLLM (100+ providers), Ollama, vLLM, Google ADK, CrewAI, Microsoft Foundry, and any custom client you build.

The SDK does not modify your AI responses. It observes, hashes, and generates tamper-evident evidence alongside your existing workflow. Your application logic stays unchanged. The witness layer runs in parallel, producing cryptographic anchors that auditors and regulators can independently verify.

Whether you run a single-model chatbot or a multi-agent orchestration pipeline, the same patterns apply. Instrumentation is additive. You can start with one pattern and expand coverage as your compliance requirements grow.

2. 8 Instrumentation Patterns

Pattern 1: Client Wrapping

Transparent proxy around any AI client. Wrapping your client adds a witness layer that records every inference without changing the response. Each call generates a tamper-evident anchor containing the model identifier, timestamp, and evidence factors.

Procedures Satisfied
AI-INF.1 AI-INF.2 AI-INF.3
Your auditor sees: AI-INF.1 PASS with timestamp and model ID for every inference

Pattern 2: RAG Provenance

Witness document retrieval alongside inference. Records which documents were retrieved, their content hashes, and relevance scores. Proves that the AI system's responses were grounded in specific source material.

Procedures Satisfied
AI-RAG.1 AI-RAG.2
Your auditor sees: Document hashes and retrieval metadata proving source attribution

Pattern 3: Tool Witnessing

Record every tool call an agent makes. When your agent calls external tools such as APIs, databases, or file systems, each call is witnessed with the tool name, input hash, and result hash.

Procedures Satisfied
AI-TOOL.1
Your auditor sees: Complete tool call chain with execution timestamps

Pattern 4: Agent Identity

Bind a persistent cryptographic identity to an agent's actions. Every anchor minted by this agent carries its identity fingerprint, creating an unbroken chain of attribution across sessions and deployments.

Procedures Satisfied
AI-ID.1
Your auditor sees: Agent identity verified across all anchors in the assessment

Pattern 5: Access Control Gate

Pre-inference authorization check. Before every inference, the SDK verifies that the requesting identity has permission to use this model with this data at this clearing level. The authorization decision is witnessed as part of the anchor.

Procedures Satisfied
AI-ACC.1
Your auditor sees: Authorization ID and policy reference for each inference

Pattern 6: Anchor Revocation

Recall a previous attestation. If a model is recalled, data is contaminated, or a policy violation is discovered after the fact, the SDK can mint a revocation anchor that cryptographically links to the original. Seven reason codes are supported, from model recall to regulatory order.

Procedures Satisfied
AI-REV.1
Your auditor sees: Revocation record with reason code and link to original anchor

Pattern 7: Model Metadata

Record model version, weights hash, and adapter stack. Proves which exact model artifact was running at inference time, preventing disputes about what was deployed when. Covers the full model lifecycle from training to serving.

Procedures Satisfied
AI-MDL.1 AI-MDL.5 AI-MDL.6
Your auditor sees: Model fingerprint matching the deployed artifact

Pattern 8: CI/CD Integration

Run the SWT3 doctor in your deployment pipeline. Validates SDK configuration, checks connectivity, and reports coverage gaps before code ships. Catches missing instrumentation before your auditor does.

Procedures Satisfied
Pre-deployment validation
Your auditor sees: Confidence that instrumentation was validated at deployment time

3. From Your Pipeline to Your Auditor's Checklist

Each pattern you adopt closes a gap in your auditor's assessment. When you add client wrapping, your auditor sees AI-INF.1 checked off in their printable checklist. When you add RAG provenance, AI-RAG.1 and AI-RAG.2 appear as verified. The assessment mapping shows exactly which regulatory requirements each procedure satisfies across 16 frameworks, including the EU AI Act, NIST AI RMF, CMMC, and SR 11-7.

Your auditor follows a framework-specific walkthrough guide that maps these procedures to their regulatory obligations. The evidence you generate through these patterns flows directly into the auditor's verification workflow. No manual evidence collection, no screenshot folders, no spreadsheets.

Start with the patterns that address your most pressing compliance requirements. Every additional pattern you adopt expands your evidence coverage without disrupting patterns already in place.