Regulatory Configuration Recipes

1. How to Read a Recipe

Each recipe has five parts:

1. Regulatory requirement -- the specific article or section cite
2. What the assessor asks -- the question you need to answer
3. Configuration -- copy-paste TypeScript code blocks, labeled by component (Middleware SDK MCP Tool)
4. Evidence produced -- which anchors appear in the ledger
5. What to tell the compliance officer -- plain-language explanation of what the config does and why it satisfies the requirement

2. Integration Levels

For detailed comparison, see the Architecture Decision Matrix in the Witness Middleware guide.

3. Recipe: EU AI Act High-Risk (Art. 9 + Art. 14)

SDK Gatekeeper mode blocks inference if the witness anchor cannot be minted:

import { Witness } from "@tenova/swt3-ai";
import OpenAI from "openai";

const witness = new Witness({
  apiKey: process.env.SWT3_API_KEY,
  strict: true,        // Gatekeeper: blocks if anchor cannot be minted
  clearingLevel: 1,
});

// Every inference is witnessed. If the ledger is down, the call is blocked.
const client = witness.wrap(new OpenAI());

Middleware Transport-layer evidence for every tool call:

import { withSWT3 } from "@tenova/swt3-mcp/middleware";

const transport = withSWT3(new StdioServerTransport(), {
  apiKey: process.env.SWT3_API_KEY,
  batchSize: 1,        // Every tool call flushed immediately
  samplingRate: 1.0,   // 100% coverage -- no sampling for high-risk
});

MCP Tool Human oversight witnessing (called by the LLM/agent after human review occurs):

// MCP tool call: witness_human_review
{
  "model_id": "gpt-4o",
  "reviewer_role": "senior_underwriter",
  "outcome": "approved_with_conditions",
  "review_duration_seconds": 120
}

Evidence Produced

• AI-INF.1 anchors for every inference (gatekeeper-enforced, blocked on failure)
• AI-TOOL.1 anchors for every tool call (transport layer)
• AI-HITL.1 anchors for every human review event (reviewer identity, decision, latency)

What to Tell the Compliance Officer

strict: true means the system literally cannot operate if the witness infrastructure is unavailable. When the gatekeeper detects missing guardrail requirements, it mints an AI-GRD.3 anchor recording the failure and raises a GatekeeperError, halting the inference pipeline. The system is rigidly controlled and cannot operate outside its bounds. This satisfies the active risk management mandate of Article 9.

Combined with AI-HITL.1 anchors from witness_human_review, the evidence proves that human oversight was exercised at the tool boundary with documented reviewer identity, decision outcome, and review latency. The assessor can verify that a qualified human reviewed the output before it was acted upon. This satisfies the human oversight requirement of Article 14.

4. Recipe: GDPR Data Minimization (Art. 5(1)(c) + Art. 25)

SDK Active governance with maximum metadata stripping:

const witness = new Witness({
  apiKey: process.env.SWT3_API_KEY,
  strict: true,
  clearingLevel: 3,   // Classified: tool names hashed, only numeric factors leave wire
});

Middleware Transport-layer evidence with same clearing level:

const transport = withSWT3(new StdioServerTransport(), {
  apiKey: process.env.SWT3_API_KEY,
  clearingLevel: 3,
  samplingRate: 1.0,
});

Evidence Produced

• AI-TOOL.1 and AI-INF.1 anchors with hashed tool names and numeric-only factors
• Cryptographic fingerprint intact and independently verifiable
• No descriptive metadata survives in the permanent telemetry layer

What to Tell the Compliance Officer

By combining active blocking (strict mode) with clearing level 3, the resulting anchors prove two things simultaneously. First, the system was rigidly controlled and could not operate outside its bounds. Second, raw PII was irreversibly purged from the witness stream the millisecond the call completed. No sensitive prompt data, tool arguments, or response content was ever persisted in the permanent telemetry layer. The cryptographic fingerprint still proves the event occurred and is independently verifiable, but the descriptive content is gone by design. The compliance telemetry stream itself is data-minimized.

5. Recipe: CMMC AU-2/AU-3 (Audit Event Generation)

Middleware This is the simplest recipe. Middleware alone satisfies AU-2/AU-3:

const transport = withSWT3(new StdioServerTransport(), {
  apiKey: process.env.SWT3_API_KEY,
  signingKey: process.env.SWT3_SIGNING_KEY,
  agentId: "claims-processor-v3",
  samplingRate: 1.0,   // Every tool call
  batchSize: 5,        // Small batches for timely evidence
});
await server.connect(transport);

process.on("SIGTERM", async () => {
  await transport.flush();
  process.exit(0);
});

Evidence Produced

• AI-TOOL.1 anchors with HMAC-SHA256 signatures
• Six content fields per anchor: tool name (what), timestamp (when), execution duration (how long), success/failure (outcome), agent identity (who), fingerprint (integrity)

What to Tell the Compliance Officer

One line of code, zero tool modifications. The middleware alone generates audit events (AU-2) with six content fields per record (AU-3). The HMAC-SHA256 signature provides non-repudiation: the assessor can verify that the anchor was minted by an authorized system by checking the signature against the registered signing key. No SDK integration or MCP server required.

6. Recipe: NIST AI RMF MEASURE 2.5 (AI System Monitoring)

SDK Drift detection witnessing after each evaluation cycle:

const witness = new Witness({
  apiKey: process.env.SWT3_API_KEY,
  strict: true,
});

// After each evaluation cycle:
await witness.witnessDrift({
  metricsEvaluated: 12,
  driftedCount: 2,
  driftScore: 0.15,
  detectionMethod: "psi",   // Population Stability Index
  threshold: 0.1,
});

Middleware Transport-layer coverage for tool execution patterns:

const transport = withSWT3(new StdioServerTransport(), {
  apiKey: process.env.SWT3_API_KEY,
  samplingRate: 1.0,
});

Evidence Produced

• AI-DRIFT.1 anchors recording drift detection results with methodology, thresholds, and scores
• AI-TOOL.1 anchors recording tool execution patterns at the transport layer

What to Tell the Compliance Officer

The SDK witnesses drift detection results with quantified methodology (PSI, KL divergence, or custom metrics), configured thresholds, and measured scores. Each drift evaluation produces a cryptographic anchor that proves the monitoring occurred, what was measured, and what the result was. The middleware provides continuous transport-layer coverage for tool execution. Together they provide evidence that the AI system's behavior is continuously tracked against baselines with documented detection methodology.

7. Recipe: SR 11-7 Model Risk Management

SDK Model integrity and adapter witnessing:

const witness = new Witness({
  apiKey: process.env.SWT3_API_KEY,
  strict: true,
  clearingLevel: 2,   // Sensitive financial data
  signingKey: process.env.SWT3_SIGNING_KEY,
});

// Witness model weight integrity
await witness.witnessModelWeights({
  modelId: "fraud-detector-v4",
  weightsHash: "sha256:abc123...",
  format: "onnx",
  parameterCount: 125_000_000,
});

// Witness active adapter stack
await witness.witnessAdapterStack({
  modelId: "fraud-detector-v4",
  adapters: ["lora-financial-v2", "domain-specific-v1"],
  mergeStrategy: "linear",
});

Middleware Transport-layer evidence with signing:

const transport = withSWT3(new StdioServerTransport(), {
  apiKey: process.env.SWT3_API_KEY,
  clearingLevel: 2,
  samplingRate: 1.0,
  signingKey: process.env.SWT3_SIGNING_KEY,
});

MCP Tools Resource consumption and forensic timeline:

// witness_resource_consumption (AI-COST.1)
{
  "model_id": "fraud-detector-v4",
  "tokens_in": 1500, "tokens_out": 200,
  "api_calls": 1, "cost_cents": 12
}

// reconstruct_timeline -- forensic history on demand
{ "model_id": "fraud-detector-v4", "window_hours": 720 }

Evidence Produced

• AI-MDL.5 anchors proving model weight file integrity (SHA-256 hash of weights)
• AI-MDL.6 anchors documenting active adapter composition and merge strategy
• AI-TOOL.1 anchors for every tool interaction at the transport layer
• AI-COST.1 anchors tracking resource consumption per model
• Forensic timeline reconstruction available on demand via MCP

What to Tell the Compliance Officer

This is the most comprehensive recipe. Model integrity is proven at the weights level (SHA-256 hash verification). Adapter composition is documented with merge strategy. Every tool interaction is witnessed at the transport layer with HMAC-SHA256 signatures. Resource consumption is tracked for cost governance. A forensic timeline can reconstruct any model's complete operational history over any time window. All evidence is produced at clearing level 2, ensuring sensitive financial data context is retained for audit while limiting distribution scope.

8. Building Your Own Recipe

Any regulatory requirement that demands evidence of AI system behavior can be mapped to a recipe. Follow these four steps:

1. Identify the regulatory article or section. What specifically does it require? Record-keeping? Human oversight? Data minimization? Continuous monitoring?
2. Does the requirement need blocking? If the system must halt when evidence cannot be produced, use the SDK with strict: true (Level 2). If passive observation is sufficient, use middleware alone (Level 1).
3. Does it need specific procedure coverage? Check the UCT Registry for the matching procedure. Each procedure maps to specific regulatory requirements across 36 frameworks.
4. Does it constrain what metadata can leave the system? Set the clearing level: 0 (analytics), 1 (standard), 2 (sensitive), 3 (classified, maximum stripping).

9. Common Questions

10. References

• Witness Middleware guide (Level 1 integration)
• SDK documentation (Level 2 integration)
• MCP server setup guide (Level 3 integration)
• UCT Procedure Registry (114 procedures, 62 namespaces, 36 frameworks)
• EU AI Act Conformity Assessment guide
• CMMC Overlay guide
• SR 11-7 Overlay guide
• Governance Assessment Workflow
• Create a free account