Treat a backtest as ready only when four records tell the same story: the run reached a final state, no unresolved error remains, the expected outputs are present, and the saved settings match the question you meant to test.
The short answer: “complete” is not the whole answer
A backtest can move through several systems before a report appears. A job can be accepted, calculated, stored, and then displayed. One layer may finish while another layer reports a problem or shows an older response.
That does not automatically mean the strategy failed. It means the run needs inspection before its result is used. The safe rule is simple: when status, errors, output, or settings disagree, pause interpretation and find the mismatch.
1. Read the final job status
Start with the run record itself. Look for a final state such as completed, failed, or cancelled. A spinner, queued label, or running state means the system has not given a final answer yet.
If the page was open during the run, refresh the record before drawing a conclusion. A visible screen can lag behind the stored job. Preserve the run identifier or timestamp in your private research notes so the result can be checked later.
2. Keep the error record, even when results appear
An error message is evidence. Do not dismiss it just because a chart or summary later appears. Record the message, the step that produced it, and whether a retry changed the state.
A parsing error, for example, can mean a display layer received an unexpected response while the calculation continued elsewhere. The result may still exist, but the disagreement must be resolved before the report is treated as clean.
Do not rewrite the strategy merely to make an application error disappear. Application errors and research results answer different questions.
3. Confirm that the output is complete
A headline score is not enough. Check whether the trade list, event counts, chart, summary, and any downloadable record belong to the same run. If one view is blank while another is populated, stop and reconcile them.
Zero trades is a valid output when the run completed and the rules never became eligible. Use the zero-trade diagnostic to separate a true no-trade result from a blocked or incomplete run.
4. Match the settings to the intended question
Confirm the market, timeframe, date range, starting assumptions, position rule, entry, exit, and risk settings. A perfectly completed run can still answer the wrong question when one saved setting drifted.
If the idea is still open to interpretation, return to the guide for writing testable trading rules. A clear specification makes a status mismatch easier to diagnose because the expected behavior is already written down.
Use a simple decision table
- All four records agree: continue to the full backtest validation checklist.
- Status is final, but an error remains: preserve the run and investigate the application or data path before interpreting performance.
- Output is partial or inconsistent: do not fill the missing pieces with assumptions. Retry only after saving the original record.
- Settings do not match the plan: keep the result as a separate test, correct the documented setup, and run a new version.
What to save in the research record
A useful run record does not need to be complicated. Save the strategy version, market, timeframe, date window, status, timestamp, visible error text, and whether trades and summary output were present. Add the next action: accept, investigate, correct configuration, or rerun.
This turns a confusing screen into a traceable decision. It also prevents a later retry from replacing the evidence that showed what went wrong.
A backtest is ready to read when its status, errors, output, and settings agree.
What this check does—and does not—prove
The four-record check helps confirm that you are looking at a coherent run. It does not validate the strategy logic, data quality, trading costs, sample strength, or future behavior. Those questions come next.
After the run is coherent, inspect individual trades, stress execution assumptions, and preserve an independent evaluation sample. Then use paper trading as a separate forward-observation step—not as proof of future performance.
This guide was informed by TradeLab product-quality review on July 29, 2026. In one test workflow, a transient response produced visible error text while the stored job later showed a final state and populated output. No performance figures from that run are used here. Historical tests are hypothetical, depend on their data and assumptions, and do not predict future results. This material is educational, not financial advice or a recommendation.