The Most Boring Module That Saved My Backtest
Multi-timeframe data alignment ensuring M15, H1, H4, D1 bars are properly synchronized with zero data alignment errors.
The Alignment Problem
V7 uses features from four timeframes: M15, H1, H4, and D1. When computing features for an M15 bar at 10:30, the H1 feature must come from the 10:00 bar (complete), not the 11:00 bar (incomplete). The H4 feature must come from the 08:00 bar. The D1 feature must come from yesterday's close. Getting this wrong introduces look-ahead bias.
S25 manages timestamp alignment across all timeframes and timezone conversions. It sounds trivial until you deal with DST transitions, partial holiday sessions, and instruments in different exchange timezones that all need to align to the same bar.
Zero Data Alignment Errors
After implementing S25, automated validation checks run on every backtest confirming zero alignment errors. The checks verify that no higher-timeframe feature uses data from a bar that has not yet closed at the time of the M15 signal. Before S25, there were 147 alignment errors in the backtest, each representing a tiny look-ahead bias.
Those 147 errors affected less than 1% of trades, but they disproportionately affected signals near session boundaries where multiple timeframe bars close simultaneously. Fixing them changed total R by only -0.4R, confirming that the errors were small but systematic.
Why Boring Infrastructure Matters
S25 is the least exciting module in the system. It handles timezone conversions, bar boundary alignment, and missing data interpolation. Nobody writes blog posts about timezone handling. But incorrect data alignment is one of the most common sources of backtest overfitting. A backtest that uses tomorrow's daily close to make today's decision will look spectacular. S25 ensures that never happens. The module validates itself on every run, producing a log of alignment checks that serves as proof that the backtest results are uncontaminated by look-ahead bias.