Escrow Runbook
Private credit funds employ analysts, not DevOps engineers. This runbook is what your IT team or a competent engineering contractor follows on the day an escrow trigger fires. Step-by-step, named contacts, expected delivery formats, smoke test included.
The Coverage Continuity Guarantee Checklist (the legal layer) has fired one of the five named triggers. Iron Mountain Technology Escrow Services or NCC Group Escrow has confirmed the trigger and is preparing the deposit release. This runbook covers what happens between the agent's release notice and a fund-side appliance back to steady-state operation.
The escrow agent (Iron Mountain or NCC Group, whichever was named in the fund's contract) sends a Trigger Notice via the contact-of-record at the fund. The notice includes the trigger event type, the verification timestamp, the signed Release License terms, and a customer-specific access credential for the agent's secure download portal.
Step 1
The fund's vendor-management lead acknowledges receipt to the agent within one business day. The acknowledgment is the agent's confirmation that the customer-of-record is intact and reachable; the agent will not release the deposit until acknowledgment is received.
Iron Mountain customer service: 1-800-934-3453 (escrow services line)
NCC Group escrow operations: [email protected] (UK) / [email protected] (US)
Codekeeper: [email protected]
The exact named contact at the agent is documented in the fund's contract addendum at signing, not on this public page.
Step 2
The fund's IT team (or designated engineering contractor) downloads the deposit using the customer-specific access credential in the Trigger Notice. Expected deposit format:
Verify the PGP signature against the agent's published release key before extracting. Hash check every file against MANIFEST.md.
Step 3
The deposit ships with a pinned dependency manifest. The IT team installs from these specific versions, not the latest available. Named ML dependencies (representative; exact versions are pinned in the deposited requirements.lock and Package.resolved):
The deposit includes a `dependencies/` directory with vendored copies of every Apple-Silicon-compatible binary in case the original distribution channel becomes unavailable. The runbook treats the vendored copies as the authoritative source.
Step 4
The deposit ships with OCI-format container images for the four runtime services:
Pull each image via standard `docker load` from the deposit's images/ directory. The deposit also includes a docker-compose.yml wiring the four services together for a single-appliance deployment, plus a k8s/ directory with Kubernetes manifests for funds that prefer cluster deployment.
Step 5
For funds that prefer source-build over the container images, the deposit's `BUILD.md` walks through the compile path on a fresh Apple Silicon Mac:
# 1. Clone the deposit into the local environment
tar -xzf covenant-escrow-2026-Q2.tar.gz
cd covenant-escrow-2026-Q2/
# 2. Verify the deposit signature and manifest
gpg --verify ../covenant-escrow-2026-Q2.tar.gz.asc
./scripts/verify-manifest.sh
# 3. Bootstrap the build environment (vendored deps)
./scripts/bootstrap.sh --offline
# 4. Build the four service binaries
make build-all
# 5. Run the smoke test
make smoke-test
The `bootstrap.sh --offline` flag forces the build to use the vendored dependency cache rather than pull from the public internet. Air-gapped deployments use this flag.
Step 6
The deposit ships with a smoke-test corpus: 12 anonymized borrower submissions across all major document types (10-K excerpts, compliance certificates, lender notices, scanned PDFs with watermarks, image-only PDFs, missing-schedule references). Run the test:
./scripts/smoke-test.sh
# Expected output:
# 12/12 documents ingested
# 8/12 graded A-D, 4/12 routed to parse-fail bucket
# Tiered alert classifier produced 3 Tier-2 signals (expected: 3)
# Density cap held at 3 signals/day (expected: 3)
# All audit-log rows written and signed
If the smoke test fails on any of the four services, the runbook directs the IT team to the relevant `TROUBLESHOOTING.md` section in the deposit. The most common cause of smoke-test failure on a fresh stand-up is a signature mismatch on the vendored dependency cache (resolved by re-running `bootstrap.sh --offline`).
Step 7
Once smoke test passes, point the fund's portfolio managers at the new endpoint. The original appliance can stay online (graceful degradation mode) until the team is comfortable with the replacement; data flows are read-only from the original to the replacement, so there is no race condition.
The audit-log of every analytical decision survives the cutover; the deposit includes the schema for the audit table so the fund's SIEM can ingest both pre- and post-cutover rows under the same ETL.
Step 8
Post-cutover, the fund maintains the deposited code in-house, engages a third-party engineering firm under the same Royalty-Free Internal-Use License, or migrates to a successor vendor on its own timeline.
Common operational tasks that the runbook documents:
training/RETRAIN.md)schemas/MIGRATIONS.md)integrations/SIEM.md)Each task has a documented procedure. None require source-level engineering for routine operation; the deposit is structured so a competent IT team handles the steady state without engineer-level skill.
Each customer can request, on a calendar-year cadence, a written attestation from the named escrow agent confirming:
The attestation is delivered directly from the agent to the fund's General Counsel under the fund's existing contract with the agent. NHN does not stand between the customer and the agent for the audit.
Funds that want to walk through Steps 1 to 8 with a live deposit before any trigger fires can request a tabletop exercise. NHN provides a sandbox copy of the most recent quarterly deposit, the IT team runs through the runbook against the sandbox, and any gaps in the documented procedure get fixed before they matter.
Email: [email protected]
Subject line: "COVENANT Escrow Tabletop Exercise Request"