Trying a hundred stop levels and keeping the best one is the fastest way to build a backtest that fails live: the best of many is, very often, just the luckiest. The Study view of the Backtest page lets you vary a recipe's parameters and then does what a careful researcher would: it chooses a configuration that is good and stable, re-does the whole search on data it hasn't seen, counts how many configurations you tried, and hands you a verdict.
What a study can and can't tell you
A study finds the configuration that would have done best on the past, and measures how much of that is likely to survive. It doesn't create an edge: if no configuration in the space has a positive risk-adjusted return in-sample, the verdict says so and stops there. Even a Robust verdict is a statement about historical data.
A study always starts from a recipe: the run on screen, or, without one, the recipe being composed (at least the legs). It varies only the parameters you choose and leaves everything else exactly as the recipe says. Open it from the Study tab of the view switch; New study starts another, and the Studies menu at the top lists past studies (with Resume and Delete). The study you are following is remembered: reopen the Backtest page and you find it again, running or finished.
The parameters are grouped like the recipe:
minval, maxval; its step is the axis' default step). Each combination computes its indicator once, then reuses it. Only numeric inputs vary: options, on/off inputs, sources, texts, times and colors stay as in the recipe (run each option from the composer and compare).For each parameter turn on vary and give from, to and step; the panel counts the values. Include «off» adds the value "this rule switched off", so the study also asks whether the exit is needed at all. Errors are explained inline (from after to, a zero step, too many values).
A target or stop in % and the same exit in $ are alternatives, as in the composer. When a parameter sets one of them, that combination switches the other off: varying the stop in $ on a recipe with a 200% stop really tests stops in $. If you vary both, the % wins wherever it is set, as in the engine. On a recipe whose stop is per leg, the stop row is the per-leg stop. Adding the stop on the whole structure as a parameter tests the two together: the engine runs both, but the composer has one stop, so a result reopened there keeps the per-leg one and says so. When both delta exit levels vary, the combinations whose lower level is not below the upper one are skipped (every position would close at its first minute), and the panel says how many.
Some things are deliberately not optimisable:
The development period (the recipe's period minus the lockbox) must hold at least about one year of trading days, or no statistic can stand.
A study runs on the server, in the background: you can close the page and come back, even after a restart. If the server restarts mid-way, the study is marked interrupted and Resume continues from the evaluations already saved. No study is ever rejected for being one too many: beyond the free compute slots it waits in a queue that rotates fairly between users, and it shows how many studies start before yours.
The progress card shows four steps (Evaluation → Walk-forward → Stress → Verdict), the current phase, the configurations evaluated, the budget spent and the elapsed time, with Cancel (or Remove from queue). During the evaluation a provisional landscape fills in: a heat map of Sharpe over the two parameters with the most values (the same two as the final grid). It is a provisional reading (some trials run on part of the days, and with more than two parameters a cell averages its combinations); in an area search some cells stay empty, the zones the search judged unpromising.
If the whole grid fits the budget, every combination is evaluated. Otherwise the area search:
Days of market stress, chosen from market data only (never from the strategy's P&L), are always included, so a trial on a subset can't look better just by skipping a crisis. The search is deterministic: the same study on the same data repeats the same steps.
The choice is therefore rarely the single best number: it is the best number that stays good when you move it a little.
The development period is split into anchored windows: each window re-runs the entire study (search and robust choice) on everything before it, and the chosen configuration is measured on the months after. The out-of-sample pieces, stitched together, form a curve that no one who picked the parameters ever saw. Its efficiency is the out-of-sample objective divided by the average in-sample objective.
The result has four tabs.
The verdict label with its one-line reason:
Below it: the robust choice against the starting recipe (what changed, parameter by parameter), and the key figures: the objective on the development period (and the recipe's), the walk-forward out-of-sample objective and its efficiency, the Δ Sharpe over the recipe with its 90% band, P&L, max drawdown, positions and the share of days traded. A chart compares the cumulative P&L of the choice (solid) and of the recipe (dashed) on the development period. A sentence says whether the gain over the recipe is likely or holds even counting every trial (a SPA test over all the configurations tried), and how many configurations are statistically equivalent to the best.
The ranking by plateau lists the top configurations with their objective and plateau score, tagging the choice, the peak (the best raw number) and a peak at the edge of the space.
Apply to backtest runs the chosen configuration as a normal backtest on the recipe's period: the same numbers, to the cent. New study starts over.
One row per window: training and test dates, the configuration chosen with only the past, its in-sample and out-of-sample objective, and whether it beat the recipe on the test. Above: the stitched out-of-sample objective, the efficiency, how many windows beat the recipe, and the parameter stability (how many window choices are equivalent to the final one). The chart is the stitched out-of-sample P&L. If the development period is too short, the walk-forward isn't computable and the verdict is Insufficient sample.
Every check has a status (ok, warning, fail, not applicable) and a plain-language message.
The tab also shows the execution stress table (nominal, costs × 1.5, costs × 2, entry +1, +2 and +5 minutes, for the choice and for the recipe), year by year P&L and Sharpe, the average daily P&L by volatility regime (terciles of the previous day's VIX; context only, never a verdict criterion), the P&L without the 5 best days and without the best 1%, and an assumptions ledger stating what was computed exactly, what was resampled and what was assumed.
The verdict is punitive by construction: Robust needs the max test, PBO, walk-forward and plateau all ok, and costs, delay and years ok (or not applicable); one strong signal is enough for Likely overfit. A failed check that isn't a strong signal (a max test failed under Sortino or Calmar, costs, years…) gives Weak.
The lockbox is the last 12 months of the recipe's period, excluded from every computation of every study of the family until someone opens it. Open the lockbox reveals the Sharpe of the choice on those unseen days and compares it with the band the walk-forward predicts for a period of that length (a two-stage block bootstrap: the uncertainty of the estimate, then the variability of new days). Inside the band: the result holds. Below: the strategy degraded, and the verdict becomes Likely overfit.
It opens once
The lockbox opens once per strategy family. After that, those days are development data for every future study of the family, and the lockbox refills only with data that arrives later. Opening it after tweaking the strategy while looking at these results unmasks nothing: open it when you are done.
Once refilled, the lockbox holds only the days after the opening. Until there are at least 120 of them, a new study says it relies on the walk-forward alone; those days still stay out of the study.
Apply to backtest runs the choice on the recipe's whole period, lockbox months included: its results show those months before the lockbox is opened. If you want the lockbox to stay a blind test, open it before you apply the choice, or read the applied backtest only up to the start of the lockbox.
Studies are saved with their results and belong to the scope you were in (your library or a shared space). The family register, with its count of studies and configurations tried and the lockbox state, is kept per family in the same scope.