What to Watch in a Strategy's First Week

A new bridge is never opened to full traffic on day one — engineers run it under load first, watching for the small discrepancies between the design model and how the actual steel behaves: a joint that flexes slightly more than predicted, a vibration under wind that didn't show up in the simulation. None of these alone means the bridge is unsafe; they mean the model and reality aren't perfectly identical, and the gap needs to be measured before trusting the model completely. A strategy's first week live is the identical exercise: not "did it make money" (a week is nowhere near enough data to tell), but "does live behavior match the backtest's assumptions closely enough to trust the rest of the model."

The core comparison: predicted vs realized

The first and most important check is comparing each trade's predicted execution — the price the backtest assumed — against its realized execution:

$\text{slippage}_t = \frac{P_{\text{realized},t} - P_{\text{predicted},t}}{P_{\text{predicted},t}}$

In words: for each trade, how far did the actual fill price differ from what the backtest engine assumed it would get, as a percentage. A backtest typically assumes some fixed cost model — say, fill at the mid-price plus half the spread. Live trading reveals whether that assumption was optimistic.

Worked example 1. A strategy's backtest assumed an average slippage of 3 basis points per trade (a conservative estimate baked into the historical Sharpe ratio calculation). In the first week live, the desk measures actual slippage across 40 trades and finds an average of 11 basis points — nearly 4x the assumption. Restated in dollars: on a strategy trading $2M notional per day, 3bps of assumed cost is $600/day, while 11bps of realized cost is $2,200/day — an extra $1,600 per day, or roughly $8,000 over the first week, silently eating into what the backtest promised. If this gap holds, the strategy's true expected Sharpe ratio, discounting for the corrected cost assumption, could be meaningfully lower than the backtested number — exactly the kind of finding that's cheap to act on in week one and expensive to discover after six months of capital allocation based on the wrong number.

The second check: is the signal itself intact

Worked example 2. Beyond execution cost, the desk checks whether the live signal values themselves match what a parallel, offline recomputation of the same signal on the same live data would produce — a pure implementation check, catching bugs in the production pipeline (timezone handling, a stale data feed, an off-by-one in the lookback window) that a backtest, run on clean historical data, would never surface. Suppose out of 500 signal computations in the first week, 480 match the offline recomputation within a tight numerical tolerance, but 20 don't — a 4% mismatch rate. Investigating those 20, the desk finds all of them involve stocks with a corporate action (a split or a special dividend) that the live pipeline's price-adjustment logic handled one day later than the offline research pipeline. That's a genuine, fixable bug — caught because someone checked signal parity in week one, not because P&L eventually looked wrong months later after enough corporate-action-affected trades accumulated to show up as unexplained drag.

What this means in practice

A first-week review typically checks, at minimum: realized versus assumed slippage, signal parity between live and offline recomputation, position sizes matching the intended risk budget, and that every trade the strategy intended to make was actually sent and filled (not silently rejected by a risk check or dropped by a connectivity issue). None of these are about whether the underlying idea is good — they're about whether the machine built to express the idea is doing what its designer thinks it's doing.