Add a compliance gate to your deployment workflow. Every build is validated before it ships. Your auditor sees evidence of automated verification.
Who this is for: You deploy AI systems through automated pipelines. This guide shows how to add compliance configuration validation to your CI/CD workflow, so every deployment is verified before it ships and your auditor sees evidence of automated validation.
Industry-agnostic by design. SWT3 is a cryptographic witness protocol that works with any pipeline tool (GitHub Actions, GitLab CI, Jenkins, Azure DevOps) and any deployment target. The validation described here applies regardless of your compliance framework or cloud provider.
The best time to find a missing compliance configuration is during CI, not during an audit. The SWT3 doctor command validates your configuration before deployment, the same way a linter catches syntax errors before runtime.
If the doctor fails, the deploy is blocked. Your auditor never sees a deployment that shipped with invalid instrumentation. The pipeline produces a pass/fail record for every build, creating an auditable trail that connects your version control history to your compliance posture.
This is not a runtime check. It runs at build time, against your configuration files, before any code reaches production. Think of it as a pre-flight checklist for compliance instrumentation.
The doctor performs eight sequential checks against your repository and environment. Each check produces a PASS, WARN, or FAIL result.
Verifies that swt3.yaml (or .swt3.yaml) exists in your repository. Without a config file, the SDK cannot determine which procedures to witness. A missing file is an immediate FAIL.
Validates that the configuration file is well-formed YAML. A syntax error here means the SDK cannot read your instrumentation settings at runtime. Malformed YAML is caught before it ever reaches a running system.
Confirms that required environment variables (API key, signing key) are set. Missing variables mean anchors cannot be transmitted to the platform or cryptographically signed. In local-only mode, only the signing key is required.
Checks that your selected profile (eu-ai-act-high-risk, nist-ai-rmf, minimal, and others) is a recognized profile. The profile determines which procedures are activated at runtime. An unrecognized profile name is a FAIL.
Validates all configuration sections: policy, trust mesh, hardware, and density policy. Malformed sections are caught before they cause silent failures at runtime. Each section has its own schema requirements.
If your configuration extends another file (using the extends directive), verifies that the referenced file exists and resolves correctly. Broken inheritance chains are caught at build time rather than at deployment.
If hardware attestation is configured, checks for TPM availability. This check warns (does not fail) if TPM is not detected but attestation is not required by your profile. CI runners typically do not have TPM hardware, so this is expected to produce a WARN in most pipelines.
Validates Model Context Protocol settings if your configuration includes MCP integration. Checks registry references, tool bindings, and policy declarations against the MCP schema.
Each check produces a PASS, WARN, or FAIL result. In CI mode (strict), any FAIL exits with a non-zero code, blocking the deployment. WARNs are logged but do not block.
The validation fits into your existing pipeline as a single step. The flow below shows how a code change moves from commit to deployment with compliance validation as a gate.
Commit
Developer commits code and swt3.yaml to the repository
Trigger
CI pipeline triggers on push or pull request
Validate
Pipeline runs SWT3 doctor in strict mode
Check
Doctor validates all 8 configuration checks
Deploy proceeds. Instrumentation is validated. Anchors will generate correctly at runtime.
Deploy blocked. Developer fixes the configuration and pushes again. No broken instrumentation reaches production.
Your auditor never sees a deployment that shipped without validated instrumentation. The doctor's exit code creates an auditable record tied to your deployment history. Your CI system already stores these results, so the evidence is generated automatically.
Setting up compliance validation in your pipeline takes four steps. No code is shown here. The SDK documentation and package include templates you can copy directly.
Run the SWT3 init command with your chosen compliance profile. This generates a swt3.yaml file tailored to your framework requirements. Available profiles include EU AI Act high-risk, NIST AI RMF, SR 11-7, and minimal configurations. The init command also validates your environment and reports any missing dependencies.
Add the configuration file to your repository alongside your application code. This file defines which procedures the SDK will witness at runtime. Tracking it in version control means every configuration change is auditable and tied to a specific commit.
The SWT3 SDK includes a GitHub Action template that runs the doctor in strict mode on every push and pull request that modifies your SWT3 configuration. Copy this template to your .github/workflows/ directory. The action installs the SDK, runs all eight checks, and fails the workflow if any check returns FAIL.
Add your SWT3 API key to your repository's secrets. This enables cloud-mode validation, where the doctor can verify connectivity to the platform in addition to local configuration checks. Without cloud mode, the doctor validates configuration syntax and structure only.
The GitHub Action template is included with the @tenova/swt3-ai npm package and the swt3-ai Python package. For other CI/CD platforms (GitLab CI, Jenkins, Azure DevOps), the same doctor command runs in any Node.js or Python environment.
When your auditor reviews your compliance evidence, they see anchors generated by a system whose configuration was validated at every deployment. This is stronger than manual attestation because:
Your auditor does not need to verify your CI/CD pipeline directly. The anchors your system generates are the evidence. The CI/CD validation ensures those anchors are generated correctly. The combination of validated configuration and cryptographic anchors creates a chain from code commit to auditor verification.
Configuration validation is the foundation. The SWT3 SDK also supports runtime witnessing, where every inference generates an anchor automatically. The CI/CD pipeline validates that witnessing is configured correctly. The runtime generates the actual evidence.
Together, they create an unbroken chain from code commit to auditor verification. The pipeline proves the instrumentation was valid when the code shipped. The runtime anchors prove the instrumentation was active when the system ran.
For a complete picture of what your instrumentation produces and where it appears in your auditor's workflow, see the What Your Auditor Sees guide.