Your observability stack already captures inference telemetry. SWT3 turns that telemetry into cryptographic compliance evidence -- same data flow, different purpose, zero additional latency.
Audience: MLOps engineers, platform teams, SRE managers, and compliance officers operating AI inference pipelines with OpenTelemetry, Datadog, Grafana, or Jaeger.
Observability tools track performance. SWT3 adds compliance attestation to the same pipeline. Same data flow, different purpose. One measures uptime. The other proves accountability. Your Grafana dashboard tells your SRE team the model is healthy. Your SWT3 anchor tells an auditor the model was operating within policy at a specific moment in time.
Observability answers one question: is it working? Accountability answers a different question: can we prove it was working within policy?
Both use the same signals -- latency, error rates, model drift, token consumption. The difference is the audience. Your SRE team watches Grafana for anomalies. Your auditor needs SWT3 Witness Anchors proving that controls were active at inference time.
Traditional observability pipelines already collect the data. The problem is that dashboards are ephemeral. A P99 latency graph from last Tuesday does not constitute regulatory evidence. It can be edited, rotated, or lost. It has no cryptographic integrity.
SWT3 solves this by attaching a witness anchor to each inference event. The anchor is hashed, timestamped, and independently verifiable. The OTel exporter sends both the observability span and the compliance anchor from a single instrumentation point. No duplicate collection. No second pipeline.
| Dimension | Observability | Accountability |
|---|---|---|
| Question | Is it working? | Can we prove it was working within policy? |
| Audience | SRE, DevOps, platform team | Auditors, regulators, compliance officers |
| Evidence format | Metrics, traces, logs | Cryptographic witness anchors (SHA-256) |
| Retention | Rolling window (7--90 days) | Immutable ledger (policy-driven retention) |
| Integrity | Editable, rotatable | Tamper-evident, independently verifiable |
| Tooling | Datadog, Grafana, Jaeger | SWT3 SDK + compliance ledger |
Every signal your observability stack already captures has a compliance counterpart. SWT3 does not replace your monitoring. It adds a cryptographic attestation layer on top of it.
| Signal | Observability Use | Accountability Use |
|---|---|---|
| Latency | P99 dashboard, alerting threshold | AI-INF.1 anchor -- proves SLA compliance at inference time |
| Model version | Canary deployment tracking | AI-MDL.1 anchor -- proves the expected model was served |
| Error rate | Alert threshold, incident trigger | AI-VIO.1 anchor -- proves violation detection was active |
| Token count | Cost tracking, budget alerting | AI-INF.2 anchor -- proves resource usage was within bounds |
| Drift score | Model retraining trigger | AI-DRIFT.1 anchor -- proves drift was detected and recorded |
The key insight: you are not collecting new data. You are attesting to data you already have. The SWT3 SDK wraps your existing inference call, captures the factors, and mints an anchor. The anchor travels through the same OTel pipeline as your traces.
The SWT3 SDK includes a built-in OpenTelemetry exporter. Every witness anchor emits an OTel span with the procedure ID, verdict, and fingerprint as span attributes. No custom instrumentation required.
Set two environment variables and enable the exporter. Anchors will flow through your existing OTel collector to whatever backend you already use.
from swt3_ai import Witness
witness = Witness(
tenant="YOUR_TENANT",
otel_enabled=True # Emits OTel spans for every anchor
)
# Set OTEL_EXPORTER_OTLP_ENDPOINT in your environment
# Anchors appear as spans alongside your inference tracesimport { createWitness } from "@tenova/swt3-ai";
const witness = createWitness({
tenant: "YOUR_TENANT",
otelEnabled: true // Emits OTel spans for every anchor
});
// Set OTEL_EXPORTER_OTLP_ENDPOINT in your environment
// Anchors appear as spans alongside your inference tracesEach OTel span includes these attributes:
| Span Attribute | Example Value | Purpose |
|---|---|---|
swt3.procedure | AI-INF.1 | Which compliance procedure was witnessed |
swt3.verdict | PASS | Whether the control was satisfied |
swt3.fingerprint | 22e18a5910f9 | SHA-256 evidence fingerprint (12 hex chars) |
swt3.anchor | SWT3-E-AWS-AI-INF.1-PASS-... | Full self-describing anchor string |
swt3.clearing_level | 1 | Data sensitivity classification (0--3) |
These attributes are searchable in any OTel-compatible backend. Filter by swt3.procedure to find all anchors for a specific control. Filter by swt3.verdict=FAIL to find compliance violations.
SWT3 anchors flow through your existing OTel collector. No vendor-specific integration code is needed. Each platform receives the same spans with the same attributes.
Route your OTel collector output to the Datadog APM intake. SWT3 anchors appear as custom spans in the APM trace view, linked to the parent inference span. Use faceted search on swt3.procedure to build compliance-specific dashboards. Set monitors on swt3.verdict:FAIL to alert your compliance team when a control violation occurs.
Send OTel traces to a Tempo backend. SWT3 anchor spans appear in the trace waterfall alongside your inference spans. Build Grafana dashboard panels using TraceQL queries filtered by swt3.procedure to show anchor verdict distribution over time. A single panel can show PASS/FAIL ratios per procedure -- your compliance posture as a time series.
Export directly via OTLP to Jaeger. The trace detail view shows each inference call with its linked witness anchor as a child span. Search by swt3.fingerprint tag to locate a specific anchor when an auditor requests evidence for a particular event. Jaeger's dependency graph will show the witness layer as a downstream service of your inference pipeline.
Vendor independence. SWT3 is not affiliated with Datadog, Grafana Labs, or Jaeger. It uses the OpenTelemetry standard -- the same protocol these platforms already consume. Switching observability vendors does not affect your compliance evidence chain.
Three procedures are most relevant to observability-driven attestation. Each procedure defines what evidence is captured, how it is hashed, and what an assessor should verify.
What it records: Model name, request latency, prompt hash, response hash, token counts, and timestamp. This is the foundational inference evidence record -- proof that an inference occurred, when it occurred, and what resources it consumed.
Factor A: Model identifier (e.g., gpt-4o, claude-sonnet-4-20250514). Factor B: Latency in milliseconds. Factor C: Token count (prompt + completion).
Verify that the model identifier in Factor A matches the organization's approved model inventory. Cross-reference the latency in Factor B against the declared SLA. A sudden latency change may indicate an undocumented model swap.
What it records: A cryptographic hash of the deployed model binary or configuration. Proves that the model served at inference time matches the approved, validated version. Detects unauthorized model changes, shadow deployments, and configuration drift.
Factor A: Model identifier. Factor B: SHA-256 hash of model weights or configuration. Factor C: Version label or deployment tag.
Compare Factor B across consecutive anchors. A hash change between anchors without a corresponding change management record is a finding. Request the organization's model deployment log and verify alignment.
What it records: Evidence that model drift was measured and the result was recorded. Does not judge whether drift is acceptable -- that is an organizational policy decision. The anchor proves the measurement happened.
Factor A: Model identifier. Factor B: Drift metric name and value (e.g., psi:0.12). Factor C: Threshold and evaluation result.
Verify that drift measurements appear at a frequency consistent with the organization's monitoring policy. Gaps in AI-DRIFT.1 anchors may indicate periods where drift detection was not operational. Ask for the monitoring schedule and compare.
The full procedure registry contains 80 AI procedures across 41 namespaces. Browse the complete list at sovereign.tenova.io/registry.
Three steps. Five minutes. Your first attested inference with OTel export.
# Python
pip install swt3-ai
# TypeScript
npm install @tenova/swt3-ai# Set your OTel collector endpoint
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
# Optional: set your tenant for cloud ledger
export SWT3_DSN="https://sovereign.tenova.io"
export SWT3_TENANT="YOUR_TENANT"from swt3_ai import Witness
from openai import OpenAI
witness = Witness(otel_enabled=True)
client = OpenAI()
# Wrap your inference call -- one line change
response = witness(
client.chat.completions.create,
model="gpt-4o",
messages=[{"role": "user", "content": "Hello"}]
)
# The SDK automatically:
# 1. Records the inference (AI-INF.1 anchor)
# 2. Emits an OTel span with swt3.* attributes
# 3. Flushes the anchor to your compliance ledgerRun the zero-config demo to see anchors locally without any API keys:
# Python demo -- no API keys, no cloud connection
python -m swt3_ai.demo
# TypeScript demo
npx swt3-demoVerify any anchor fingerprint at sovereign.tenova.io/verify. All verification runs client-side using SHA-256. No data leaves your browser.