The difference between proving compliance by hand and proving it with math. No code. Just the before and after.
You build AI systems. Eventually, someone will ask you to prove what your system did, when it did it, and whether it followed the rules. This guide shows what that proof looks like today versus what it looks like with the SWT3 protocol.
Your auditor sends an email: "Prove your guardrails were active on March 14."
You dig through application logs. You hope the timestamps are UTC. You correlate entries across three services, matching request IDs that were formatted differently in each one. You find what you think is the right window.
You screenshot a Grafana dashboard and paste it into a Word document. You add a caption: "Figure 3: Guardrail activation rate, March 14." You know this screenshot proves nothing on its own. Anyone could fabricate it. But it is what your auditor expects.
You write an attestation letter. "I, the undersigned, certify that our AI system was operating within policy on the date in question." You sign it. Your manager countersigns it. You both know you are attesting to something you cannot independently verify after the fact.
Your auditor reads the package. They ask a follow-up question: "How do I know the model version running on March 14 was the same one you tested in February?" You open a spreadsheet where someone was supposed to track model versions. The last entry is from January. You start over.
This takes 40 to 80 hours per audit cycle. Every time. The evidence is fragile, the process is manual, and the result depends entirely on whether the auditor trusts you personally.
You add a single function call that wraps your existing AI client. Your application's behavior does not change. The response your code receives is identical. No new dependencies to manage, no infrastructure to deploy, no database to maintain.
In the background, the SDK generates a witness anchor for each inference -- a tamper-evident record containing the procedure ID, evidence factors, timestamp, and a SHA-256 fingerprint. The fingerprint is derived from the evidence itself, so any modification to the record after the fact would produce a different hash. The math is self-proving.
These anchors flow to your auditor's assessment checklist automatically. When your auditor opens the checklist, each procedure shows its current status with a verifiable anchor attached. There is no evidence to prepare, no screenshots to capture, no attestation letters to draft.
The next time someone asks "prove your guardrails were active on March 14," the answer is already waiting for them.
See the Quickstart Guide for implementation details. Full API reference at /docs.
You instrument your AI client
One function call wraps your existing code
SDK generates witness anchors
Tamper-evident records, one per inference
Anchors stored with fingerprints
SHA-256 hash locks the evidence
Auditor opens the checklist
Each procedure mapped to its evidence
PASS with a verifiable anchor
Cryptographic proof, not promises
Your auditor can independently verify any anchor at sovereign.tenova.io/verify by entering the fingerprint. No account required. No network dependency. The math either checks out or it doesn't.
SWT3 is an open cryptographic protocol, not a vendor platform. The fingerprint formula is published. The SDK is Apache 2.0. Any party can independently verify an anchor using nothing more than SHA-256 -- the same hash function that secures every Bitcoin transaction and TLS certificate on the internet.
Your auditor does not need an account, a subscription, or any relationship with TeNova to verify your evidence. The protocol is designed so that trust is derived from mathematics, not from any vendor relationship.
The Unified Control Taxonomy maps 80 AI procedures across 16 regulatory frameworks, including EU AI Act, NIST AI RMF, CMMC, and SR 11-7. Each procedure has a published definition, assessment methodology, and framework crosswalk. The registry is open and namespace-aware.