AI Model Escrow Integration

1. The Escrow Gap

AI model escrow services secure model artifacts for business continuity: weight files, training schemas, hyperparameters, adapter configurations, and deployment specifications. When a vendor fails, gets acquired, or suffers a catastrophic loss, the escrowed artifacts enable recovery. This solves the custody problem.

It does not solve the provenance problem.

Three questions that escrow alone cannot answer:

1. Is the deployed model the same one that was escrowed? Model files can be swapped, updated, or corrupted between escrow deposit and production deployment. Without runtime verification, the escrow receipt is a historical artifact with no bearing on current operations.
2. Has the model drifted from the escrowed baseline? Even if the correct weights were loaded at deployment, statistical drift over time means the model's behavior may no longer match the escrowed snapshot. The escrow agent has no visibility into production behavior.
3. Were the escrowed adapters and quantization settings actually used? A fine-tuned, quantized model is not one artifact -- it is a stack: base weights, LoRA adapters, quantization parameters, safety filters. Escrowing only the base weights creates a false sense of custody.

2. Regulatory Landscape

Four regulatory frameworks now require or strongly imply that AI system operators maintain verifiable custody of model artifacts with traceable integrity from development through deployment.

Regulation	Article / Requirement	Escrow Role	SWT3 Role
EU AI Act	Art. 43 -- Conformity Assessment	Preserves model artifacts for NB review	Proves deployed model matches escrowed artifacts
EU AI Act	Art. 11 -- Technical Documentation	Custodies documentation artifacts	Timestamps and fingerprints documentation state
EU AI Act	Art. 12 -- Record-Keeping	Stores baseline records	Immutable, timestamped, fingerprinted event log
EU AI Act	Art. 15 -- Accuracy, Robustness	Preserves baseline for comparison	Drift detection proves ongoing accuracy (AI-DRIFT.1)
DORA	Art. 11 -- ICT Risk Management	Recovery artifact for digital resilience testing	Proves operational state before/after recovery
NIS2	Art. 21 -- Supply Chain Security	Secures model supply chain artifacts	Traces model provenance across supply chain
CRA	Annex I -- Essential Requirements	Archives software integrity baselines	Continuous integrity verification (AI-MDL.5)

Article 43: The Conformity Assessment Loop

Under Article 43, Notified Bodies performing third-party conformity assessment are granted full access to training, validation, and testing datasets, and in exceptional cases, access to the trained models themselves. This means the NB needs to verify that the system in operation matches the system described in the technical documentation.

Escrow provides the artifacts. SWT3 provides the proof that those artifacts were the ones actually running. Together, they close the Article 43 loop: the NB can verify the escrowed model, then verify that SWT3 anchors confirm the same model was deployed throughout the assessment window.

3. The Integrity Chain

The integrity chain connects seven stages from training completion to Notified Body verification. The SHA-256 hash of the model weights is the thread that runs through every stage.

Step 1-2: The hash computed at training time is the "truth anchor." It enters the escrow vault alongside the weight file. The escrow agent records the hash, deposit date, and depositor identity. This hash never changes.

Step 3: Before deployment, the model must exist in an approved internal registry. The AI-MDL.8 procedure witnesses this registry check: factor_a = expected entries, factor_b = verified entries. If the model is not in the registry, deployment should not proceed.

Step 4-5: At deployment time, hash_model_file() computes the SHA-256 of the loaded weight file. witness_model_weights() compares this runtime hash against the escrowed hash via the expected_hash parameter. If the hashes match, factor_b = 1 (PASS). If they diverge, factor_b = 0 (FAIL) -- the deployed model is not the escrowed model.

Step 6: After deployment, witness_drift() monitors statistical drift from the escrowed baseline using the baseline_hash parameter. This catches behavioral divergence even when the weight files have not changed.

Step 7: The NB queries the SWT3 ledger for all AI-MDL.5 anchors for the tenant, verifies factor_b = 1 (hash match) across the assessment window, and correlates with the escrow deposit receipt. If every anchor shows a hash match, the integrity chain is unbroken.

4. SDK Integration

4a. Hash at Escrow Deposit

Compute the SHA-256 hash of the model weight file at training completion. This hash enters the escrow deposit alongside the weight file.

Python

from swt3_ai import Witness

# Hash the model file (static method -- call once, not per-inference)
info = Witness.hash_model_file("/models/production-v2.safetensors")

print(f"Hash:   {info.file_hash}")
print(f"Size:   {info.file_size_bytes} bytes")
print(f"Format: {info.format}")

# Store info.file_hash in your escrow deposit record
escrow_hash = info.file_hash

TypeScript

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

const info = Witness.hashModelFile("/models/production-v2.safetensors");

console.log(`Hash:   ${info.fileHash}`);
console.log(`Size:   ${info.fileSizeBytes} bytes`);
console.log(`Format: ${info.format}`);

const escrowHash = info.fileHash;

4b. Witness at Deployment (AI-MDL.5)

At deployment time, hash the loaded model and compare against the escrowed hash. The expected_hash parameter creates the bridge between escrow and production.

Python

from swt3_ai import Witness

witness = Witness(api_key="your_key", tenant_id="your_tenant")

# Hash the model being deployed
info = Witness.hash_model_file("/models/production-v2.safetensors")

# Witness with escrow hash as expected value
payload = witness.witness_model_weights(
    info,
    expected_hash=escrow_hash,       # From escrow deposit receipt
    lifecycle_stage="deployment",
)

# payload factor_b: 1.0 = hash match (PASS), 0.0 = mismatch (FAIL)
print(f"Fingerprint: {payload.anchor_fingerprint}")
print(f"Match: {'YES' if payload.factor_b == 1.0 else 'NO -- DEPLOYED MODEL DIFFERS'}")

TypeScript

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

const witness = new Witness({ apiKey: "your_key", tenantId: "your_tenant" });

const info = Witness.hashModelFile("/models/production-v2.safetensors");

const payload = witness.witnessModelWeights(info, {
  expectedHash: escrowHash,
  lifecycleStage: "deployment",
});

console.log(`Fingerprint: ${payload.anchorFingerprint}`);
console.log(`Match: ${payload.factorB === 1 ? "YES" : "NO -- DEPLOYED MODEL DIFFERS"}`);

4c. Adapter and Quantization Attestation (AI-MDL.6, AI-MDL.7)

For fine-tuned or quantized models, witness the full artifact stack -- not just the base weights.

Python

from swt3_ai import Witness
from swt3_ai.types import AdapterInfo

witness = Witness(api_key="your_key", tenant_id="your_tenant")

# Witness the adapter stack (AI-MDL.6)
adapters = [
    AdapterInfo(name="safety-lora-v3", adapter_hash="abc123..."),
    AdapterInfo(name="domain-qlora-finance", adapter_hash="def456..."),
]
witness.witness_adapter_stack(adapters, base_model_id="production-v2")

# Witness quantization settings (AI-MDL.7)
witness.witness_quantization("gptq", bits=4, group_size=128)

TypeScript

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

const witness = new Witness({ apiKey: "your_key", tenantId: "your_tenant" });

// Witness the adapter stack (AI-MDL.6)
witness.witnessAdapterStack(
  [
    { name: "safety-lora-v3", adapterHash: "abc123..." },
    { name: "domain-qlora-finance", adapterHash: "def456..." },
  ],
  "production-v2",
);

// Witness quantization settings (AI-MDL.7)
witness.witnessQuantization("gptq", { bits: 4, groupSize: 128 });

4d. Drift Detection Against Escrowed Baseline (AI-DRIFT.1)

Periodically compare production metrics against the escrowed baseline. The baseline_hash parameter links drift measurements back to the escrowed model.

Python

# Periodic: compare production metrics against escrowed baseline
witness.witness_drift(
    metrics_evaluated=12,
    drifted_count=0,
    drift_type="prediction",
    baseline_hash=escrow_hash,       # Links drift back to escrowed model
    detection_method="psi",
    threshold=0.25,
)

TypeScript

witness.witnessDrift({
  metricsEvaluated: 12,
  driftedCount: 0,
  driftType: "prediction",
  baselineHash: escrowHash,
  detectionMethod: "psi",
  threshold: 0.25,
});

5. The Open-Weight Custody Problem

The current model landscape creates a spectrum of custody complexity. Proprietary models (API-only access) have simple custody: the provider controls the runtime, and the escrow artifact is the API contract. Open-weight models create a fundamentally different challenge.

When an organization downloads open weights, applies LoRA adapters, quantizes to INT4, and deploys behind a custom safety filter, the "model" is no longer a single artifact. It is a stack of four independent layers, each of which can change independently.

Model Type	Escrow Artifact	SWT3 Procedures	Complexity
Proprietary API (GPT-4o, Claude)	API contract + SLA	AI-MDL.8	Low
Open-weight base (Llama 4 405B)	Weight file (.safetensors)	AI-MDL.5, AI-MDL.8	Medium
Fine-tuned open-weight	Base weights + adapter files	AI-MDL.5, AI-MDL.6, AI-MDL.8	High
Quantized + adapted (Muse Glimmer INT4 + LoRA)	Base + adapters + quant config	AI-MDL.5, AI-MDL.6, AI-MDL.7, AI-MDL.8	Highest

Each layer has its own SWT3 procedure. The witness anchors form a composite integrity chain. A Notified Body can verify each layer independently: "Were the base weights correct? Were the adapters the ones documented? Was the quantization method what was declared?"

For detailed guidance on Meta model deployments specifically, see the Llama Stack Compliance Witnessing Guide.

6. Clearing Levels and Escrow

SWT3 clearing levels determine how much context survives in the witness anchor. This directly affects what evidence an escrow agent or Notified Body can extract.

Clearing Level	Context Preserved	Escrow Implications
Level 0 (Analytics)	Full context: model IDs, hash values, file paths, format	Suitable for internal escrow verification. Escrow agent can directly compare hashes.
Level 1 (Standard)	Model IDs preserved. Raw content hashed.	Suitable for external escrow agent sharing. Hash values visible for comparison.
Level 2 (Sensitive)	Model-specific context redacted. Only factors and fingerprint survive.	Escrow agent cannot see model details. NB can verify factor_b = 1 (hash match) without seeing the hash itself.
Level 3 (Classified)	Only the fingerprint survives.	Escrow verification requires the Factor Handoff Protocol.

At Clearing Level 2 and above, the Factor Handoff Protocol enables secure transfer of hash comparison evidence without exposing the underlying model details. The escrow agent or Notified Body receives the comparison result (factor_b = 1 or 0) without ever seeing the hash values, model identifiers, or file paths.

7. Assessor Verification Checklist

For Notified Body assessors performing EU AI Act conformity assessment, the following checklist verifies the escrow-to-production integrity chain.

8. Integration Architecture

The architecture separates artifact custody (escrow) from operational evidence (SWT3). Neither system stores the other's data. The SHA-256 hash is the only shared element.

Key separation: SWT3 does not store model weights, training data, or any raw artifacts. It stores fingerprints, factors, and verdicts. The escrow agent stores the artifacts. Together they form the complete evidence chain without either system needing access to the other's data.

9. Quick Start

Install:

# Python
pip install swt3-ai

# TypeScript
npm install @tenova/swt3-ai

Hash, witness, verify -- three lines:

from swt3_ai import Witness

witness = Witness(api_key="your_key", tenant_id="your_tenant")
info = Witness.hash_model_file("/models/production-v2.safetensors")
payload = witness.witness_model_weights(info, expected_hash="your_escrow_hash")

Full SDK documentation: SDK Docs. Create a free account: Sign Up.

10. References

• EU AI Act (Regulation 2024/1689) -- Articles 11, 12, 15, 43
• DORA (Regulation 2022/2554) -- ICT Risk Management, Digital Operational Resilience
• NIS2 (Directive 2022/2555) -- Supply Chain Security, Business Continuity
• CRA (Regulation 2024/2847) -- Cyber Resilience, Software Integrity
• EU AI Act Conformity Assessment Guide -- Full Article 9-15 mapping for Notified Bodies
• Supply Chain Integrity Guide -- Forensic gap analysis, dependency witnessing
• Llama Stack Compliance Witnessing -- Open-weight GPAI obligations for Meta deployments
• Factor Handoff Protocol -- Clearing Level 2-3 evidence transfer methods
• Business Continuity Plan -- Key-person risk, recovery procedures
• Assessor Evidence Matrix -- Complete evidence mapping for conformity assessment
• UCT Registry -- 280 procedures, 77 frameworks
• SDK Documentation -- Python, TypeScript, and 8 additional language SDKs