How many sequential optimize-then-score windows to run. Two is the floor and the reason is structural rather than a tuning preference: parameter drift is measured between consecutive fold winners, and a single fold has no consecutive pair, so it would report the strongest possible stability having measured nothing. The ceiling is a platform setting; exceeding it is rejected.
OptionalinShare of each fold's window spent optimizing, the rest being where its winner is scored. Omit to take the platform default. Lower values leave more data to score on and, on short sessions, are what let the requested fold count tile the data at all. Must be within 10..90.
Opt a sweep into walk-forward validation.
Attaching this changes what the sweep does, not just how much of it runs. Instead of scoring every parameter vector once over the whole range, the data is cut into sequential folds; each fold optimizes the whole grid on its own window and then scores only its winner on the window immediately after — data that winner was never chosen on. The question it answers is not "which parameters won" but "does re-optimizing this periodically actually work".
Omit it and nothing about the sweep changes, including the shape of the response.
It costs folds × grid. Four folds over a 500-point grid is roughly 2000 backtests where the plain sweep is 500, which is why it is opt-in. The platform rejects the request outright when that product exceeds its sweep budget.
It is a different sweep, not a variant of one. Two requests that differ only in this block do not deduplicate against each other.
The answer arrives as
walkForwardon the SweepResult — see Sweep.result for how to read it.