A backtest is easy to rerun and surprisingly easy to describe incompletely. A chart or a result table rarely tells the whole story: which data was used, what was assumed about execution, and how many parameter variations were tried all matter. I want a research note to make those choices visible so that a later run can answer the same question rather than quietly changing it.
Define the study before running it
Start with a narrow question and write down its scope:
- Instrument and contract rules: identify the symbol, exchange, contract month or continuous-contract method, and any roll convention.
- Time span and clock: record the start and end dates, timezone, session definition, and bar interval. The same dates can represent different sessions if the clock or session rules change.
- Data source and fields: note where the data came from, when it was retrieved, which fields are present, and any provider permissions or adjustments that matter. Save the source file or a stable identifier and checksum when possible.
- Strategy and parameters: record the strategy version, every parameter value, entry and exit rules, and the assumptions that affect orders. Avoid changing several things at once if you want to understand what caused a different result.
Also inspect the data before interpreting results. Look for missing or duplicated bars, unexpected gaps, inconsistent timestamps, contract-roll discontinuities, and values that do not fit the instrument. A backtest can be perfectly repeatable and still be misleading if its input is wrong.
Keep three kinds of evidence separate
A historical backtest applies rules to historical data using a model of how orders might have behaved. Its output depends on both the data and the execution assumptions; it is not a record of live fills.
Parameter optimization evaluates a set of candidate configurations. It can help show how results vary across a defined parameter range, but it does not establish that the best-looking configuration will continue to work. The more alternatives are tried on the same history, the easier it is to select one that fits noise. Research on backtest overfitting discusses why selecting a historical winner can fail out of sample (Bailey et al., “The Probability of Backtest Overfitting”).
Paper Trading runs in a simulated brokerage environment. It can reveal workflow and integration behavior under the conditions observed during that period, but it is not the same as historical simulation or live execution. Demo samples are another separate thing: they are for product exploration, not evidence about a strategy.
Algoryn's current public build includes a local historical backtest and bounded parameter-optimization workflow for MGC. That statement is deliberately narrow: it is not a claim of a general-purpose optimizer for every instrument or a claim that any strategy has been validated. The tool can organize a study; the researcher still needs to review the data, configuration, and assumptions.
Record costs and execution assumptions
Write down the commission and fee schedule used, spread and slippage assumptions, order type, fill timing, and any constraints on partial fills or rejected orders. If a component is omitted or simplified, say so. A result calculated before costs should not be compared casually with one that includes them, and an assumed fill should not be described as an observed fill.
Keep the actual parameter values with the run, not just a label such as “baseline.” A useful record also notes the application or code version, data version, run date, configuration file, and any manual edits. If a later release changes behavior, those details make it possible to distinguish a new result from a rerun of an older setup.
Reduce the temptation to overfit
Choose a limited parameter range for a reason before reviewing the output. Separate the data used to develop a rule from data reserved for later evaluation, and avoid repeatedly moving the boundary or retuning after seeing the reserved period. Time-series data needs chronological care; shuffling bars can leak future conditions into a test.
Do not focus only on the single highest-scoring parameter set. Inspect nearby settings, different market periods, and the sensitivity of the result to reasonable cost and data assumptions. A broad, stable-looking neighborhood is still not proof of future performance, but a sharp isolated peak is a reason to ask more questions. Record every trial or at least the full search range so that the amount of selection is visible.
Preserve the research trail
For each study, keep a short note containing the question, instrument, dates, data source and identifier, strategy version, parameter set, cost model, validation split, software version, and output files. When changing the method, create a new versioned record instead of overwriting the old one. Summarize what changed and why; do not retrofit an explanation after seeing a favorable result.
The goal is not to make every study look convincing. It is to make the next person—including a future version of me—able to reproduce the same run, see its limits, and decide what still needs testing. None of these steps turns historical or Paper results into a promise of future performance, and this article is not investment advice.