Your gold model learns every week. Did the test use the same calendar?

The clock is part of the method

Imagine a proposed gold forecasting system that retrains once each weekend and then keeps its parameters fixed for the trading week. A historical test instead refits the model before every five-minute prediction. Both procedures can respect chronological order, yet they do not represent the same operating system. The second receives a much more frequent opportunity to adapt. Its apparent responsiveness cannot automatically be attributed to the weekly process.

This article proposes a research design, not a tested gold strategy. The issue is distinct from whether the data rows are in date order. We need to specify when the model is allowed to change and reproduce that policy in the evaluation. Otherwise, the label ‘walk-forward’ conceals a consequential implementation choice.

Choose a forecast origin and a deployment interval

The forecasting text by Hyndman and Athanasopoulos describes evaluation at successive forecast origins, with training observations preceding the evaluated outcomes. It also distinguishes one-step from multi-step evaluation. These concepts help separate when a forecast is issued from how far ahead it is intended to describe. A method tested for one interval should not inherit credibility at every other horizon.

My protocol would name four times: the latest eligible training observation, the start of fitting, successful completion, and activation of the resulting model. For a hypothetical weekend update, a failed training job would leave the prior version active or suspend predictions according to a rule written beforehand. It would not grant the backtest a replacement model that production never finished building.

Source notes: [1] Hyndman and Athanasopoulos — Time series cross-validation

A window size does not specify an update policy

Scikit-learn’s TimeSeriesSplit provides ordered training and test indices, an optional maximum training size and a gap expressed in samples. Its documentation notes that equally spaced samples are needed for test folds to represent comparable durations. A collection of irregularly timed signal events therefore needs explicit calendar handling rather than assuming that equal row counts mean equal weeks.

I would record the policy in plain language before coding: for example, a hypothetical ninety-session rolling training window, a weekly refit, and predictions issued during the next five sessions. An expanding window would retain older eligible observations instead. Neither choice is intrinsically superior. They represent different balances between retaining experience and emphasizing recent conditions, which the experiment must evaluate rather than settle by assertion.

Source notes: [2] scikit-learn — TimeSeriesSplit

Ask when an outcome became usable

A signal can begin before the training cutoff while its eventual label is still unknown. River’s progressive-validation implementation explicitly allows a delay before the target is revealed for learning. That is a useful reminder that a timestamp on the original setup does not establish when its outcome became available.

For a target-based gold study, I would retain both the event time and the receiver time of the evidence used to classify it. A late target report cannot be retroactively included in a model trained earlier. Unresolved cases should follow a declared treatment. A cutoff that waits only for favorable outcomes to arrive would change the training population. This requirement concerns knowledge available to the model; it does not authenticate a broker fill.

Source notes: [3] River — progressive validation implementation

Score the deployed sequence, not the best replacement

Each prediction should retain its model version, issue time, intended horizon and eventual scoring record. When a later refit arrives, earlier predictions remain attached to their original version. Recalculating yesterday’s prediction with today’s parameters creates a revised demonstration, not a record of what the system could have said yesterday.

I would compare the proposed retraining policy with a frozen baseline using the same eligible prediction times and outcome definitions. Report coverage as well as errors. A version that fails to produce a forecast during difficult periods should not appear stronger merely because those periods vanished from its score. Overlapping forecast horizons also share information, so a large count of predictions is not automatically a large count of independent tests.

Make the next update reviewable

Before the run, save the data-window rule, update frequency, fitting budget, activation rule and failure fallback. After it, preserve actual execution times and departures from the plan. Changes to that policy begin a new evaluation segment. The practical gain is not administrative neatness: another researcher can distinguish a useful forecast rule from an unusually helpful update schedule.

Gold Terminal can help organize dated signal identities and reported events for this work. Research Lab provides the wider evidence framework. Neither service turns reference observations into verified trading profits. This article supplies no measured model advantage, return or win rate; broker fills, spread, commissions, slippage and P&L are unverified. The premium image is conceptual, not a historical chart.