A backtest can show that a strategy worked on historical data, but it cannot guarantee that the first live order will fill at the expected price. Spread, fees, slippage, and available liquidity can turn a clean Sunday result into a different Monday outcome.
The Sunday result looked complete
At 10:47 p.m. on Sunday, a trader reviews the report one more time. The equity curve rises in a controlled line. The rules are simple. The maximum drawdown stays within the trader’s limit. Every historical entry appears to receive the intended price.
The result looks finished because the backtest has answered one narrow question: how would this strategy have performed against the historical data provided?
It may not have answered a harder question: could a real account have entered and exited those positions at those prices, with the available order book, spread, fees, and order size?
That distinction matters most on the first live signal. The strategy has moved from an analytical environment into a market where someone else sets the price you can actually receive.
Apollo 13 shows how a hidden assumption becomes operational
In April 1970, Apollo 13’s crew was on the way to the Moon when an oxygen tank in the service module exploded. The crew, James Lovell, Jack Swigert, and Fred Haise, had to use the lunar module as a lifeboat while mission controllers at NASA worked through the consequences.
The mission did not fail because the crew had ignored every risk. It failed after a system that had appeared workable encountered a condition that exposed a dangerous weakness. The outcome remained uncertain while engineers developed procedures to conserve power, manage carbon dioxide, and bring the spacecraft home.
The mission ultimately returned safely to Earth. The incident and recovery are documented in Jim Lovell and Jeffrey Kluger’s book Lost Moon, as well as NASA’s Apollo 13 mission records.
A trading backtest has the same kind of boundary. The historical test may be internally consistent, yet the first live order can expose assumptions that were invisible inside the test: a narrow spread that widens, a fee omitted from the model, or enough market depth for a small historical order but not for the current position.
The analogy has limits. A trade is not a spacecraft emergency. The useful connection is narrower: a system can look sound until it meets the conditions that its test environment did not represent.
What to inspect before treating a backtest as usable
Start with the execution assumptions.
If the test enters at the last traded price, ask whether a real market order would have received that price. If it assumes a fixed spread, compare that assumption with the instrument’s observed spread during the periods when signals appeared. If it excludes commissions, funding, borrow costs, or exchange fees, add them before judging the result.
Then examine position size. A strategy may have worked with a small historical order while a larger live order would consume several levels of the order book. The average fill could move away from the signal price. That difference is slippage, and it can turn a small expected edge into a loss after costs.
The test should also preserve what was knowable at the time. Look-ahead bias can enter through revised data or indicators calculated with information that became available only after the trade. Survivorship bias can make a universe look healthier by excluding assets that later disappeared. Overfitting can make a rule set match old noise instead of a repeatable pattern.
A practical review should record each assumption in plain language:
- What price starts the trade?
- What fees apply?
- How much slippage is modeled?
- How much liquidity is available?
- What happens when the order is only partially filled?
- What data was available at the exact decision time?
This is the same discipline described in Backtest Assumptions: Why Evan Rejected Monday’s Live Signal. The question is not whether the historical curve looks attractive. The question is whether the test describes a trade that could have been executed.
Make the first fill a checkpoint, not a verdict
A paper-trading period can help separate strategy behavior from execution risk. It will not reproduce every live condition, but it can reveal whether signals arrive when expected, whether position sizing follows the rules, and whether the modeled costs are remotely plausible.
For a live approval workflow, the first signal should be treated as a reviewable event. Check the current spread, estimated fees, expected slippage, order size, and remaining daily risk before approving anything. If the live conditions differ materially from the backtest assumptions, rejection can be the correct decision.
That is the role of an approval gate in TraderCoach. The AI can generate and queue a signal, while a human reviews the order before execution. The gate does not remove market risk or make a backtest reliable. It preserves a decision point between “the historical test passed” and “this order should be placed now.”
Apollo 13’s recovery depended on recognizing that the mission had entered a different operating condition and adapting procedures accordingly. A trader can apply the smaller version of that lesson on Monday morning: inspect the conditions the backtest could not see, and require the live order to earn approval on its own terms.
Educational content, not financial advice.
Comments
No comments yet.