A strategy “survives” when its rules, costs, fills, and risk limits remain acceptable on data that did not shape it. A beautiful in-sample equity curve is only the start. Build the rule set before reading outcomes, separate development from evaluation, test execution assumptions, preserve failed variants, and move to forward evidence under a capped risk plan.
Backtest workflow: define the decision and constraints → freeze objective rules → choose data and fill assumptions → create development and untouched evaluation periods → log every eligible signal → calculate net metrics with uncertainty → stress parameters and regimes → forward-test unchanged rules → scale only under written review gates.
What “Survives” Means
It does not mean the strategy is guaranteed to make money or will work in every market. It means the frozen process remains inside predeclared tolerances when exposed to unseen or forward data. Those tolerances might cover net expectancy, drawdown, loss clustering, trade frequency, slippage sensitivity, rule adherence, and—where relevant—an account’s contractual loss limits.
Write the pass, restrict, and stop decisions before the evaluation window. If you decide what counts as acceptable after seeing the result, the “test” becomes another development round.
1. Define the Strategy Before Testing It
Start with one falsifiable hypothesis: under a named market context, a specific entry and exit process may produce net positive expectancy within a stated risk budget. Then convert it into a versioned rule sheet.
| Rule field | Record before the test | Failure to avoid |
|---|---|---|
| Universe | Symbols, contract mapping, venue, trading hours | Adding only markets that worked |
| Setup | Observable entry conditions and invalidation | “Looks strong” or hindsight labels |
| Execution | Order type, timing, fill and slippage model | Assuming every touch fills |
| Exit | Stop, target, time exit, partials, gap handling | Choosing exits from the completed path |
| Risk | Sizing rule, concurrency cap, daily/account stop | Changing risk to rescue a result |
| Version | Rule ID, date, rationale, permitted change process | Mixing several strategies in one report |
The trading-plan template provides a practical boundary between a declared strategy and a discretionary explanation added after the trade.
2. Choose Data and an Execution Model
Record the data source, symbol mapping, timezone, session calendar, corporate-action or contract-roll treatment, missing-bar policy, and earliest/latest timestamps. A test is not reproducible if a later user cannot recover the same information set.
Model every cost that the intended execution can create: commission, exchange or platform fees, spread, slippage, funding, borrow, currency conversion, and partial fills where relevant. Apply the cost rule consistently to winners, losers, and skipped signals.
Bar Data Is Not the Intrabar Path
OHLC bars show the open, high, low, and close—not necessarily the order in which price visited the high and low. If a stop and target can both be touched inside one bar, the result is ambiguous without lower-timeframe or tick evidence. Choose a conservative deterministic rule and flag ambiguous trades.
TradingView’s official documentation also notes that Bar Replay history varies by symbol, interval, data type, and plan, and that historical versus realtime calculations can differ for repainting scripts. Verify the current limits and behavior for the exact test rather than treating a chart as a complete market archive.
3. Separate Development From Evaluation
Use development data to form and revise the strategy. Keep at least one later block untouched for the frozen version. For time series, preserve order: random shuffling can leak later regimes into earlier decisions.
Record every variant tried—indicators, thresholds, sessions, stops, targets, markets, and exclusions. Bailey and colleagues’ work on the probability of backtest overfitting explains why the number of trials matters: testing many alternatives makes a standout historical result easier to select by chance.
A single holdout is not magic if you inspect it repeatedly. Once its result changes the rules, it has joined development. Create a new untouched period or move to prospective evidence.
4. Backtest Without Seeing the Future
For a manual test, reveal bars sequentially, decide using only information available at the timestamp, and log the signal before advancing. For code, prevent lookahead in higher-timeframe values, indicator state, survivorship filters, revised data, and same-bar fills.
Log eligible signals even when they are skipped. A record needs enough information to reproduce the trade:
- strategy and version;
- signal, entry, exit, and evaluation timestamps;
- symbol, side, session, and market context;
- planned entry, stop, target, size, and risk;
- actual or modeled fills and every cost;
- result in currency, percent, and R where valid;
- rule-pass, ambiguity, skip, and data-quality flags.
Do not stop the sample on a convenient winner or extend it only after a loss. Freeze the date range or signal-count rule before the run.
5. Analyze the Result Without Magic Thresholds
Expectancy in R is:
E[R] = P(win) × average win R − P(loss) × average loss R
The formula is descriptive. A positive estimate does not prove the future distribution. Show its components, trade count, date range, costs, missing fields, and concentration. The expectancy guide explains the unit and common calculation errors.
| Metric | Question it answers | What it cannot prove |
|---|---|---|
| Net expectancy | Average outcome per observation under this sample | Stable future edge |
| Profit factor | Gross profit divided by gross loss | Quality without sample and concentration context |
| Maximum drawdown | Worst observed peak-to-trough path | Worst possible future loss |
| Loss streaks | Observed clustering of losing outcomes | A fixed maximum streak |
| Cost sensitivity | Whether plausible friction erases the estimate | Exact live fills |
| Rule coverage | How often decisions were reproducible | Profitability |
There is no universal 100-trade minimum, 1.5 profit-factor gate, or allowed percentage gap between backtest and forward results. Required evidence depends on dependence between trades, frequency, regime coverage, costs, effect size, and the risk of the decision.
6. Stress the Strategy, Not Just the Equity Curve
A robust candidate should not depend on one exact parameter, one month, or one favorable market. Re-run predeclared tests that answer specific failure questions:
- raise spread, slippage, and commissions;
- delay entry or worsen fills under a consistent rule;
- shift key parameters across a sensible neighborhood;
- split results by market, session, volatility, direction, and regime;
- remove the largest winner and the best period as sensitivity checks;
- reorder or resample outcomes only with assumptions stated;
- test position overlap and account-level risk constraints.
A cliff—where one tiny parameter change destroys the result—is more informative than another optimized peak. Keep the failed tests in the evidence package.
7. Forward-Test the Frozen Version
Run the unchanged rules on new market data in replay, paper trading, shadow logging, or minimum size. Forward evidence tests more than P&L: signal visibility, decision latency, missed trades, spread and slippage, execution ambiguity, and whether the rules can be followed in real time.
Compare the same definitions used in the historical test. A difference is not automatically failure; first separate market regime, cost, implementation, sample uncertainty, and rule drift. The backtest-versus-live guide provides the reconciliation map.
8. Go Live With a Risk Contract
Start at a size that makes process evidence useful without allowing one short sample to threaten the account. Set trade, day, correlated-exposure, strategy, and account limits before activation. For prop accounts, model the exact program’s loss calculation, reset time, commissions, floating P&L treatment, and phase—never a generic “firm limit.”
The risk-per-trade guide connects one position to the account budget. Define review triggers separately from automatic kill switches:
- continue: evidence remains within the frozen operating envelope;
- restrict: reduce risk or eligible contexts under a prewritten rule;
- review: data, execution, or regime evidence is incomplete or contradictory;
- stop: a hard account limit, implementation break, or invalidating condition fires.
Do not declare a strategy dead because live drawdown is a fixed multiple of historical drawdown. Historical maximum drawdown is one observed path, not a ceiling. Use the strategy-abandonment framework to distinguish evidence decay from ordinary variance and execution failure.
Backtesting for Prop Constraints Is a Different Objective
A strategy can have positive net expectancy and still be unsuitable for a particular challenge or funded account. Raw return does not encode the path rules that decide whether the account survives. Build a second evaluation layer for the exact program, phase, region, account size, and rule version the trader intends to use.
Replay the strategy’s timestamped P&L through the program rules without changing the trades to improve the outcome. At minimum, record:
- whether loss is calculated from balance, equity, or another reference;
- whether floating P&L, commissions, fees, or overnight positions enter the limit;
- the daily reset boundary and timezone;
- static versus trailing maximum-loss behavior;
- minimum-day, consistency, concentration, news, holding, and payout conditions that actually apply;
- what happens when several positions share risk at the same time.
Do not optimize the strategy directly against one program’s historical rule set and then call the resulting curve a general edge. Keep market-strategy evidence separate from rule-fit evidence. Program terms can change; the strategy hypothesis and editorial verdict need a new review when the canonical rule snapshot changes.
Decision boundary: “The strategy had positive net expectancy in this test” and “this exact account path stayed within this exact program’s rules” are two different claims. Both need evidence before a challenge attempt.
The Backtest Report You Should Keep
A result is most useful when another person—or you three months later—can reproduce what happened. Save one immutable package for every version that reaches evaluation:
- Strategy card: rules, version, change log, allowed discretion, and invalidation.
- Data card: source, symbols, timestamps, timezone, missing data, contract or corporate-action treatment, and known limits.
- Execution card: order types, intrabar assumptions, spread, commission, slippage, funding, and ambiguous-fill policy.
- Experiment registry: every tested variant, its purpose, and whether its result influenced later choices.
- Trade ledger: every eligible signal, accepted or skipped trade, raw fields, calculated fields, and exception.
- Results: development, untouched evaluation, sensitivity, regime, and concentration views using the same definitions.
- Decision record: continue, restrict, review, or stop; who decided; which evidence was missing; and the next permissible test.
Keep the raw rows beside the summary. Screenshots and a smooth equity curve are supporting evidence, not substitutes for the ledger. If an upstream data correction or rule change alters the result, create a new version and preserve the previous package.
How TSB Makes the Test Reproducible
Trader’s Second Brain connects versioned setup definitions, imported or manual trade records, Backtester filters, reports, and Coach evidence. Backtester can isolate a saved setup or setup version and compare it with the rest of the selected history. Journal fields preserve account, date, symbol, session, side, setup, costs, notes, and review context when those fields exist.
That is the product’s strength: the strategy claim stays attached to inspectable rows. If a setup is weakly tagged, a required stop is missing, or the selected evidence is too thin for a verdict, the system can qualify or refuse the conclusion instead of inventing precision. Once a version is live, the same structure exposes rule drift and cost differences between historical, forward, and live cohorts.
TSB recognizes 328 exact import profiles and has normalized 600K+ imported trades. These figures describe ingestion coverage and observed import volume—not users, the sample behind this guide, proof of an edge, or promised results.
TSB is our product. We disclose that ownership because this guide recommends its evidence workflow.
Methodology Note
- Research: backtest-selection claims are bounded to Bailey and colleagues’ published framework; no universal sample or metric threshold is inferred.
- Platform facts: TradingView replay/history and repainting caveats are linked to official support pages and no plan price or fixed data depth is copied into the article.
- Product facts: TSB setup registry/version, Backtester filters, trade fields, and evidence boundaries were checked against current server code.
- Removed claims: guaranteed profitability language, fixed 100/200-trade rules, profit-factor grades, forward-test percentage bands, mandatory timeframes, fixed live-drawdown multipliers, and generic prop rules were not carried forward.
Primary references: Bailey et al., Probability of Backtest Overfitting; TradingView Bar Replay history; and TradingView historical/realtime behavior.
Final Verdict: A Backtest Is an Evidence Pipeline
Freeze the question before producing the answer. Define the strategy, data, execution model, costs, evaluation window, and decision gates before reading the result.
Preserve uncertainty. Show the sample, regimes, failed variants, ambiguous fills, concentration, and sensitivity. A clean metric without those boundaries is easy to overread.
Make live trading the next controlled test. Forward-test unchanged rules, start under a risk contract, and investigate deviations before scaling or abandoning the strategy. That is how a historical pattern earns the right to face new data.
