# Deployment validation checklist — REMIT

**What this is.** The operational counterpart to the published threat model (`/security`): what the bank's own teams run, and check, before and at go-live. Every item names the specification section it comes from. Where a step is ours rather than yours, it says so. Owner: SG Systems. Last reviewed 2026-09-19 against `architecture-spec.md` and `architecture-implementation.md`.

**How to read it.** Items are grouped by the team that executes them. "Verify" means your team confirms it; "Ceremony" means your people hold the keys; "Readout" means a number you read before you decide. Nothing here requires SG Systems to be present or trusted; that is the point.

---

## 1. Network team

| # | Step | Source |
|---|---|---|
| 1.1 | **Verify the branch WAN interface has no default route** and the network configuration is sealed. The appliance has two 10 GbE ports, one to the branch LAN and one to the WAN router; the WAN port carries no default route. | implementation §13.1, §2.2 enforcement point C |
| 1.2 | **Re-run the egress probe.** The appliance attempts every endpoint on an enumerated list of 142 targets a cloud-native system would call (vendor endpoints, telemetry sinks, update servers, model registries, public DNS resolvers) and asserts each attempt fails at the boundary. The result must be **0 of 142 reachable before go-live; this is a gate, not a report**. The target list and procedure are published with the probe so your team can run it and extend it. | implementation §10, §11.1 step 7, §13.5 |
| 1.3 | **Treat the probe as evidence, not proof.** A negative test proves only what was enumerated. It does not prove no path exists. The claim that no route exists at all is a network configuration fact that your team verifies (1.1); the probe is evidence of it. | implementation §14 item 12 |
| 1.4 | **Choose and review the intake crossing: data diode, or allow-listed mTLS relay.** A diode is a physical gap. The relay is a policy-enforced gap: one source, one port, one cipher suite, relay-initiated only, the core never calls out. The relay is cheaper to operate and the weaker of the two, and **the egress probe does not test inbound policy**, so the relay configuration must be reviewed by your network security team. Do not treat the relay as equivalent to a diode. | implementation §8.3, §14 item 4 |
| 1.5 | **Confirm the branch-to-core link directionality.** Branch initiates both streams; the core never opens a connection toward a branch; allow-listed ports only. | implementation §6.1, Appendix C point B |
| 1.6 | **Confirm the build enclave has no inbound network interface** and that cartridges reach the core by physical media through a quarantine host or a one-way diode. | implementation §3.3, §8.3, Appendix C points D and — |

## 2. Security and key custody

| # | Step | Source |
|---|---|---|
| 2.1 | **Ceremony: branch signing key generated in the TPM 2.0.** Every node signs its own ledger entries and proof records with an Ed25519 key. At the edge the key is generated inside the TPM, never leaves it, and is sealed to the platform state. The public key is exported to the core key history at install; the first entry in the branch ledger is a genesis `KEY_INIT` signed by the key itself. | implementation §9.3 option 1, §11.1 step 3 |
| 2.2 | **Ceremony: activation key held in your HSM.** The key that authorises a cartridge to go live is held in a dedicated HSM (YubiHSM2 or a network HSM, PKCS#11), non-exportable, policy-enforced. Alternatively, dual-control PIV smartcards, one held by compliance and one by IT infrastructure, both required. No single person can put a cartridge into production. SG Systems never holds a key that can sign a decision. | implementation §9.3 options 2–3 |
| 2.3 | **Ceremony: disk encryption recovery key split.** Volumes are LUKS-encrypted; the recovery key is split by Shamir 2-of-3 among your custodians, not held by SG Systems. | implementation §11.1 step 2, §13 |
| 2.4 | **Verify the OS image hash** against the value published to your records before racking, and secure boot enabled. | implementation §11.1 step 1, §13.1 |
| 2.5 | **Confirm key rotation is itself a record.** A rotation is a `KEY_ROTATION` ledger entry signed by both the old and the new key; old public keys are retained permanently so a seven-year-old record still verifies. A replaced TPM board means a new key, a rotation entry, and no interruption to deciding. | implementation §8.6, §9.3 |
| 2.6 | **Verify masking, and that unmasking is never an API grant.** Consoles and read APIs show personal data masked by role; unmasking is a human, permissioned, audited act. | architecture-spec §7.2 |
| 2.7 | **Know what tamper-evidence does not cover.** An insider with database write access *and* the signing key can rewrite the chain, which is why key custody is specified separately (2.1–2.2). Tamper-evidence is forensic, not preventive. Nothing in the ledger is encrypted by default; confidentiality comes from disk encryption, VLAN isolation and masking. | implementation §5.3 |

## 3. Identity team

| # | Step | Source |
|---|---|---|
| 3.1 | **Register the consoles against your IdP.** REMIT holds no user accounts. Human identity is your LDAP for groups, SAML 2.0 or OIDC for browser sign-in; a REMIT session is a bank session. Where there is no modern IdP, LDAP bind with a signed group-to-role mapping is the fallback. | implementation §9.1 |
| 3.2 | **Review the group-to-role mapping** in REMIT Admin, where it is visible, signed and auditable. Roles are `remit:reviewer`, `remit:compliance`, `remit:admin`, `remit:head-of-risk`, `remit:auditor`, `remit:ingestion`, `remit:ops-manager`; what each may see and do per surface is the matrix in §9.2. | implementation §9.1–9.2 |
| 3.3 | **Issue integration principals from your own CA.** A machine integration authenticates with an X.509 client certificate issued by the bank's CA, registered in a signed config entry carrying scopes (which workflows, which case classes, which directions: ingest, event-consume, verify, act), rate limits, and a **named human owner resolved through the IdP**. No long-lived bearer secrets; mTLS only. | architecture-spec §7.1 |
| 3.4 | **Confirm that a principal can never hold a `remit:*` role.** Roles are human and come from group membership; principals have scopes. This is the rule that prevents an integration from accreting administrative rights. A principal with no named owner is an orphan account that fails your own access review; do not register one. | architecture-spec §7.1, implementation §9.1 |
| 3.5 | **Confirm the auditor role has no live access.** Verification happens on a separate workstation from exports; the auditor role has no console write path and no live system access. | implementation §3.4, §9.2 |
| 3.6 | **Budget for integration effort.** Directory schemas, SAML attribute names and CA policies differ at every institution; this is where deployment weeks go. | implementation §14 item 6 |

## 4. Model risk and compliance

| # | Step | Source |
|---|---|---|
| 4.1 | **Readout, then acceptance: the standard, measured on your cases and accepted as a record.** Before any live case, the workflow is scored on a held-out calibration set of your past decisions, and the gate summary shows measured coverage against the required floor, automation rate, deferral rate, calibration freshness and drift, each with a plain-language gloss. The readout is a measurement, not a decision. The decision is a `CALIBRATION_ACCEPTED` ledger entry, recorded by your compliance officer as a named actor, carrying the cartridge version, the class and the licence in force, measured coverage against the required floor, the **conditional error rate given emission** (the figure that matters once automation is live; it can be several times α when auto-emission is rare), mean prediction-set size, the α in force and the calibration-window bounds. Without that entry a class cannot leave `gate` for `auto`. | product-spec §3.3 gate summary; architecture-spec §1.3, §6.5; implementation §11.2 |
| 4.2 | **Understand what the guarantee is.** The true option lies in the kept set with probability at least 1 − α, for any model and any data distribution, under exchangeability of calibration and live cases. It is a frequency across cases, not a promise about any one; under drift the bound is void, and a stale calibration sends every case to a person. | architecture-spec §1.3, §5.4 |
| 4.3 | **Readout in shadow mode: the deferral rate.** Day one is shadow mode: the workflow reads, scores, gates and records every case and executes nothing; every case is human-worked; agreement and disagreement are logged per case and both feed the calibration pool. The **deferral rate is the number that sizes the core hardware**, because the core GPU is sized for the deferred slice; it is measurable in shadow mode **before any hardware is bought**. If real volume differs from the design points by more than about 2×, the bill of materials is revisited before the quote. | product-spec §1.1, §3.6; implementation §11.2, §13 sizing corollary |
| 4.4 | **License auto-execution per outcome class, or not at all.** Cartridge mode is part of the signed artifact, not a runtime setting: `shadow` executes nothing; `gate` permits execution only for classes licensed for auto-execution; `auto` is full per-class licensing. Mode transitions are signed activations with canary and rollback. Options declared human-only can never be executed by the machine. | architecture-spec §5 (cartridge mode), §5.4; product-spec §3.6 |
| 4.5 | **Confirm policy changes are proposals, not live edits.** A change to α or a severity flag is written to the build enclave's change queue and lands in the next signed cartridge. Nobody can change the bound on a running system, which is what makes "the bound in force at the time" checkable. | implementation §9.2 notes |
| 4.6 | **Know the recalibration workflow and its order.** Triggered by a drift alarm, a full recalibration pool, an expired calibration TTL, or an operator request: freeze the current weights, re-score the most recent labelled cases, recompute the threshold, verify coverage, sign, bump the version, canary, activate or roll back. Weight retraining is the last lever, never the first, and it always rebuilds the calibration table. | architecture-spec §5.3, §5.5 |
| 4.7 | **Confirm the fail-safe table.** Missing or corrupt calibration, expired TTL, or an active drift alarm puts the gate in `STALE` and every decision escalates; a weights-hash or base-model-hash mismatch means the cartridge refuses to activate; the core being unavailable means cases queue and nothing is emitted from a set of size greater than one. The failure mode is always "ask a person", never "guess". | architecture-spec §5.4 |
| 4.8 | **Confirm rollout is ringed and promotion is never automatic.** Shadow on the whole estate, then core staging with full re-derivation of the audit pack and compliance sign-off, then one canary branch for at least 24 h holding the deferral envelope with no drift alarm, then 10% of branches for 72 h, then the remainder. Abort is automatic on a drift alarm, a coverage breach or a determinism-check failure; rollback is a human action with a recorded actor. The previous cartridge is never deleted. | implementation §11.2–11.3 |

## 5. Go-live gate and post-go-live discipline

| # | Step | Source |
|---|---|---|
| 5.1 | **Go-live gate.** All of: OS image hash verified; recovery key split held by your custodians; branch key generated in the TPM and its public key in the core history; link agent enrolled with an mTLS certificate; first cartridge imported through quarantine and activated under dual control; the smoke test producing the byte-identical score vector recorded in the cartridge's audit pack; **egress probe at 0 of 142**. | implementation §11.1 |
| 5.2 | **Schedule anchoring, and staff it.** The chain head is anchored on a schedule (default daily at 23:59 local, per node): signed by the node's hardware-protected key, written to an append-only anchor table, exported to write-once media, and included in the daily compliance report. Anchoring is what defeats tail truncation. | implementation §5.3 |
| 5.3 | **Accept that anchoring is a human discipline.** If a site skips its daily anchor, the tail of its chain is unverifiable against truncation and the tamper-evidence argument weakens. The system alerts on a missed anchor; **an alert is not a control**. Shorter anchor intervals are available at a cost. Decide who owns the anchor and what happens when it is missed. | implementation §14 item 7 |
| 5.4 | **Run the determinism check.** A fixed probe input is re-scored periodically on a known cartridge; any byte difference in the result is an alert, because it means a runtime or quantisation drift that would silently break re-derivation. | implementation §10.1 |
| 5.5 | **Rehearse degraded mode, and frame it honestly.** With the core unreachable a branch still ingests on all channels except chat, reads and normalises documents, scores, gates and records, auto-executes only the cases the gate allows, queues the rest locally with SLA clocks running, lets a reviewer resolve deferred cases with the same constrained decision form (dual approval still required for high-severity classes), runs drift monitors, and keeps anchoring locally. It cannot receive cartridge or corpus updates or ship labels inward until the link returns. **This is a quality dip, not equivalence**: deferred cases get a human and at best a small local model, not the core's reasoning. No decision is lost and no standard is lowered. | implementation §6.2, §14 item 5 |
| 5.6 | **Decide who archives the runtimes.** Re-deriving a decision years later needs the exact pinned runtime build the cartridge recorded; someone must hold every build ever shipped for the retention period, SG Systems as part of support or the bank as part of records custody. Open per deployment; decide it before go-live. | implementation §11.5, §14 item 10 |
| 5.7 | **Confirm the time source.** Anchoring and calibration expiry depend on a monotonic clock; sites with no time source degrade to local time and are flagged. | implementation §14 item 11 |
| 5.8 | **Verify offline, from exports.** On a workstation that has never been on a REMIT network, run the published verifier against an export bundle, the cartridge, and your public key history: signature status, key validity at decision time, chain state, and re-derivation of the scores, the threshold and the kept set. No SG Systems service, network or licence is needed. If SG Systems disappears, every decision remains provable for the retention period. | implementation §3.4, §5.4, §9.3 |

## 6. Deliberately absent

These are not gaps in the checklist. They are decisions, and a reviewer should find them stated.

| What | Why | Source |
|---|---|---|
| **No remote update path.** | Cartridges, weights and corpora are built on an offline workstation, signed, and cross into the runtime by physical media or a one-way diode. Nothing is updated from the network side. | implementation §3.3, §8.3 |
| **No remote cartridge authoring.** | What the machine may decide is never editable from the network side of the boundary; no integration scope can change it. | architecture-spec §7.6 |
| **No egress to any cloud model.** | There is no connector class that can cross the air gap; inference, storage and telemetry are all local, with no remote write, crash reporter or update check. | implementation §10; product-spec §4.5 |
| **No "ask the model" endpoint and no bulk export of personal data.** | The decision is the only unit exposed, and export crosses the boundary only through the write-once path with a manifest. | architecture-spec §7.6 |
| **No public status page.** | Nothing of ours runs outside your perimeter, so there is nothing to report on; all metrics, logs and traces are local, with dashboards per role and alerts routed to your own channels. | implementation §10.2 |

---

This checklist is published so your teams can validate the deployment without trusting us. A step you cannot complete is a step we will not go live with.