Validate a strategy with Walk-forward

View full-size screenshot ↗

Define what will be unseen#

Walk-forward runs an in-sample optimisation, selects its parameters and then tests them on the following out-of-sample period. It repeats this for each planned window. Every candidate and validation uses the complete underlying instrument/account graph with fixed size and execution assumptions.

Choose dates and rules before reading the validation outcomes. Repeatedly changing a strategy after inspecting the same out-of-sample interval turns that interval into development data. Walk-forward improves the structure of a research experiment; it does not guarantee future returns.

Configure the analysis#

Add a Walk-forward item. Its configuration has Setup, Queue and History. Setup contains Strategy, Windows & data, Costs, Contract, Venue & feed, and Account & risk.

1. Choose the exact algorithm and symbol. The parameter table includes declared strategy ranges; sizing and execution economics remain fixed.
2. Select Optimization method and Target. Use the same objective meaning as ordinary optimisation.
3. Choose Rolling or Anchored, number of windows, in-sample ratio and optional purge gap.
4. For Rolling, set Window days and Step days. The step cannot be shorter than the out-of-sample duration, avoiding overlapping validation folds. For Anchored, these rolling-only fields do not apply.
5. Set the UTC data range, resolution, source and tick-callback policy. Review feed/account, costs, instrument grid, simulated account and risk settings.
6. Read the server-generated window preview. It shows in-sample, purge and out-of-sample spans, covered dates and unused tail days. Fix any window-count mismatch before starting.
7. Read the footer's projected windows × combinations, then Start Analysis or ⌘/Ctrl+Enter.

Rolling keeps an in-sample window of fixed length and advances it. Anchored keeps the initial in-sample start and adds earlier observed data as time progresses. A purge gap excludes observations between the two phases; it is not extra validation data.

For the default explicit 180-day rolling window at an in-sample ratio of 0.7, integer splitting produces 125 in-sample and 55 out-of-sample days. Use the preview's actual dates rather than mental rounding.

Use presets and coverage correctly#

Symbol spec · <symbol> (<feed>) fills contract economics from Instrument Manager and resets costs. Review what changed. Saved presets retain costs, contract, venue and account values; modified fields show an override marker.

The coverage line and Earliest data help choose an available range. A larger calendar lookback cannot manufacture missing provider history. Futures selection and supported recorded depth use the feed's exact contract. Spot-crypto environments must match the chosen venue profile. Unsupported accounting policies stay visible with a blocker and can be explicitly removed; they are not silently discarded.

While analysis runs, inputs lock. The footer shows the current window/phase and Cancel analysis. ⌘/Ctrl+. invokes cancellation; Escape does not cancel. Closing the item leaves server work running.

Read results at three levels#

The run bar identifies method, target, mode, windows, date range and status. Raw / Annualised changes how supported window values are presented. Check the original target before interpreting an annualised number.

The KPI row includes Robustness, average in-sample/out-of-sample values, Degradation, profitable validation windows and Stitched OOS. Read the breakdown and worst window, not only the coloured robustness value. Scalar target comparisons can be awkward for minimisation-style objectives or near-zero in-sample metrics.

The window table shows timelines, IS/OOS metrics, degradation, efficiency and selected parameters. Open a completed window to inspect its in-sample optimisation and its one complete out-of-sample backtest. Running windows cannot open; finished windows can open before the parent finishes when artifact IDs are available.

The stitched OOS presentation combines window return outcomes. It is not a broker account replay across every fold and does not establish joint intraday drawdown. Use each validation backtest's own contract and ledgers for execution evidence.

Inspect validation detail#

The lower detail includes an equity chart and Price, Trades and Orders tabs. They are paged independently. A bar page can contain up to its displayed limit while the complete validation has more bars; likewise, trade/order pages are not necessarily the full ledger.

Use previous/next window, Reload, or Open Optimisation. Keyboard navigation in the result panel includes ↑/↓ to choose a window, Enter to reload it, O for its optimisation and 1/2/3 for Price/Trades/Orders. A marker-limit warning means the current chart cannot show every marker; use a smaller range/page for inspection.

Queue and recover#

Queue builds durable batches with a name, maximum active parents, attempts and algorithm list. Commas, semicolons or new lines separate names; duplicate names are visibly ignored. Start only after Setup forms a complete valid request. The queue list and its summary expose progress and failures.

History filters by algorithm or symbol and groups runs by date. Open a run with Enter. A failed child or missing artifact can fail the parent; completion requires every planned window's metrics and persisted child identities. Do not describe a failed parent as a completed validation because some rows look attractive.

For a child-load error, use Reload and inspect the named artifact. For window mismatch, adjust the range/count/step and recheck preview. For an API outage, typed values remain and Retry now retries the intended host. Preserve the previous run, make the correction and start a newly identified experiment.