Sandbox-to-Live Readiness Checklist

The most common failure mode is production-only error codes that never appeared in sandbox. The broker rejects an order with an error code the adapter doesn't recognize, the error classification logic defaults to "retry," and the system repeatedly resubmits the same rejected order, sometimes entering a position multiple times or exhausting rate limits within minutes. The fix is explicit error contract tests for every error category and a default classification of "non-retryable" for unrecognized error codes.

Use the smallest position size your broker allows, typically a single share of a low-priced stock or a fractional share. The goal is not to test profitability but to verify that orders enter and exit correctly, fills are reported, positions update, and the kill switch works. Once you've confirmed one complete entry and exit cycle live, you can scale to your intended position sizes. Many systems also use a "shadow mode" phase where the strategy generates signals and the system submits orders, but a human approval step is required before each order reaches the broker.

A kill switch is a mechanism to immediately halt all automated trading, cancel all open orders and stop new order submissions, with a single action. It should work independently of the strategy code: a bug in the strategy that causes it to stop responding shouldn't also disable the kill switch. Implement it as a flag in a shared data store (database, environment variable, or file) that the order submission path checks before every submission. The kill switch test (Blocker item in this checklist) verifies that activating it actually prevents new order submissions within one order cycle.

A position size guardrail is a hard limit in your order submission code that rejects any order larger than a configured maximum (e.g., never submit an order for more than 500 shares or more than $10,000 notional). This prevents a bug in your position sizing calculation from accidentally submitting an order 100× your intended size. It must be a hard code check, not just a strategy-level parameter, strategy bugs can override strategy-level parameters, but they can't override a check embedded in the adapter layer itself.

Before every deployment that changes integration behavior, any change to the adapter layer, any change to order routing, any broker API version update, or any addition of a new order type or asset class. For pure strategy changes (signal logic, position sizing) that don't touch the integration layer, you can run only the relevant sections (risk limits, kill switch) rather than the full checklist. When in doubt, run the full checklist; it takes 20-30 minutes of real verification work and prevents hours of debugging live failures.

Anything depending on real counterparty behavior: actual rate limit accounting, genuine rejection reasons from the risk system, real settlement and buying power updates, live latency, and how the broker reports asynchronous state changes under load. These can be prepared for but not confirmed beforehand, which is the argument for a first live session at minimal size whose purpose is observation rather than return. Marking them explicitly as production-verified keeps the checklist honest about what sandbox testing established.

A defined trigger, a named person able to act on it, and the specific sequence to execute: halt new order submission, cancel resting orders, decide whether to flatten or hold existing positions, and record the state at the moment of the stop. It should also state where positions and cash will be reconciled afterwards and who confirms the system is genuinely stopped. A plan that exists only as an intention to turn it off usually costs time at exactly the point when time matters.

With a person watching who can intervene, rather than relying on alerting alone, because the first session is where unknown failure modes appear and alerts only cover anticipated ones. Useful things to watch directly are order acknowledgement latency, rejection reasons, the running difference between internal and broker positions, and whether any order reaches a state the model does not recognize. Scheduling the session at a time when that attention is available is part of the readiness decision.

A tick against an item is not reviewable later. Recording what was tested, when, in which environment, and what the observed result was turns the checklist into something that can be audited and reused for the next deployment. It also exposes items that were assumed rather than exercised, which is the usual reason a checklist passes and the first live session still fails. Keeping the evidence alongside the release record makes the connection to a specific version explicit.