Escrow Agreement

The deposit must include all artifacts required to reproduce the model's behavior. This goes far beyond traditional source code.

• Training Data Lineage: A complete, documented history of all datasets used, including provenance and transformation steps.
• Model Weights & Architecture: The final trained weights, the model's topology definition, and the exact framework version.
• Training & Inference Code: The full codebase for data preprocessing, the training loop, hyperparameter configurations, and the inference serving stack.
• Environment Specification: A containerized environment (e.g., Dockerfile) or a strict conda/pip lockfile to ensure bit-for-bit reproducibility.

A passive escrow is useless. The agreement must mandate a rigorous, automated verification process to prove the deposited assets work.

• Automated Training Test: A CI/CD pipeline that ingests the deposited data and code to train a new model from scratch, comparing its performance against a deposited benchmark.
• Inference Consistency Check: A suite of unit tests that feeds a holdout dataset to the deposited model and validates that the outputs are functionally identical to the vendor's production API.
• Hallucination Rate Benchmark: For generative models, the verification must measure the Grounding Score and factual consistency of the rebuilt model against the original.

The agreement must unambiguously define the technical and business failures that trigger a release of the source code to the beneficiary.

• Technical Bankruptcy: The vendor ceases operations without a successor to maintain the service.
• Critical Service Abandonment: The vendor stops providing critical updates or security patches for a defined period.
• Material Breach of SLA: A persistent failure to meet uptime or performance guarantees, specifically tied to model degradation like Concept Drift.
• Regulatory Non-Compliance: The vendor fails a mandatory Conformity Assessment and cannot remediate, putting the licensee at legal risk.

The escrow agreement must pre-negotiate the intellectual property rights that activate upon release, especially for complex AI components.

• Forking License: A perpetual, royalty-free right to modify and use the deposited code and weights for internal business continuity, not commercial resale.
• Open-Source Component Handling: A clear delineation of rights for any open-source libraries or models (e.g., Llama, Mistral) included in the deposit, respecting their original licenses.
• Data Rights: Explicit permission to use the deposited training data to retrain or fine-tune the model, addressing potential copyright issues identified in a Copyright Infringement Scan.

An escrow is a living artifact. The agreement must define a technical and legal cadence for keeping the deposit current with the production model.

• Event-Driven Updates: An automated trigger that pushes a new deposit upon every major model version release or significant Data Drift Detection event.
• Scheduled Cadence: A mandatory quarterly or bi-annual full deposit refresh, regardless of version bumps, to capture incremental fine-tuning.
• Differential Deposit: A mechanism to store only the delta of changed weights (e.g., LoRA adapters) and code to reduce storage and transfer complexity.

The escrow agent must maintain a security posture equal to or greater than the vendor's, protecting the highly sensitive model assets.

• Air-Gapped Storage: The master copy of the deposit must be stored in an Air-Gapped Environment, physically disconnected from the public internet.
• Encryption at Rest: All deposited artifacts must be encrypted with a key held by a neutral third party, not the escrow agent alone.
• Access Control Audit: Immutable logs of any access to the deposit, with multi-party authorization required for any verification or release activity, preventing Model Extraction attempts.