Operating paths
Backtest job methodology
A backtest job is a finite historical evaluation of one strategy revision. It starts with a selected revision, a historical time range, Strategy Variable values, starting balances, and simulator settings. It runs through the requested range, records results, and terminates. In the current target-position execution path, a backtest job evaluates both the selected revision and the Target Position Executor behavior under recorded simulator assumptions.
Backtest jobs provide evidence for comparing strategy revisions under explicit assumptions. They do not predict live fills or guarantee future performance.
For detailed result interpretation, see Backtest result metrics and Simulator assumptions and data completeness.
What a backtest job evaluates
Section titled “What a backtest job evaluates”A backtest job evaluates a selected strategy revision against historical market data.
The runtime path is:
Historical market data server -> Strategy engine -> Target Position Executor -> Venue Simulator
The strategy engine evaluates the revision and emits target positions. The Target Position Executor converts target positions into order activity. The Venue Simulator records simulated execution under the configured assumptions.
- Market data Live or historical market data sources.
- Strategy engine Runtime evaluation of the selected compiled revision.
- Target Position Executor Target-position intent converted into order activity.
- Venue Simulator Simulated execution destination and assumptions.
- Account state Live or simulated positions, fills, balances, and order state.
- Results Recorded metrics, telemetry, and review context.
- Backtest path Finite backtest job boundary.
- Revision-owned Immutable strategy revision logic and settings.
- Run settings Run-provided values, balances, ranges, or assumptions.
This means a backtest job result reflects more than strategy signal logic. It also reflects the current target-position execution path, starting balances, fees, slippage, latency, liquidity assumptions, fill model, data coverage, and simulator limitations.
For the shared executor boundary, see Target-position execution model.
Inputs that define a job
Section titled “Inputs that define a job”Every backtest job has revision context, run context, and simulator context.
| Input group | Examples |
|---|---|
| Revision context | Strategy, revision, validation state, compile output, fixed node parameters, venue, and instrument. |
| Run context | Historical time range, starting balances, Strategy Variable values, job owner, creation time. |
| Simulator context | Fees, slippage, latency, liquidity assumptions, fill model, and simulator limitations. |
| Data context | Requested historical range, available data, complete segments, and detected gaps. |
Strategy Variables are run-provided values for exposed node parameters. They let users evaluate a revision with concrete values for a specific job without changing the revision’s fixed logic.
Venue and instrument belong to the revision. They stay visible with the job because they affect data selection, simulator assumptions, result interpretation, and promotion decisions.
Job lifecycle
Section titled “Job lifecycle”Backtest jobs move through a finite lifecycle.
| State | Meaning |
|---|---|
drafting | The user is filling out the job parameters. |
provisioning | Structure is preparing the selected revision and runtime path. |
running | Historical market data is driving the selected revision. |
completed | The job finished and results are available. |
failed | The job stopped before completion and exposes an error reason where available. |
When a job fails, review the selected revision, historical range, Strategy Variable values, starting balances, simulator settings, and data coverage before retrying.
Results and recorded context
Section titled “Results and recorded context”A completed backtest job records the result and the context that produced it.
Common result fields include:
- PnL.
- Max drawdown.
- High-water mark.
- Continuous-time Sharpe ratio.
- Rolling position.
- Trade count.
- Event count.
- Data completeness.
- Assumptions used by the Venue Simulator.
Metrics describe what happened under the recorded settings. They do not establish what happens in a future market, in a live deployment, or under different simulator assumptions.
| Result field | How to read it |
|---|---|
| PnL | Profit and loss under the selected historical range, starting balances, and simulator assumptions. |
| Max drawdown | Largest decline from a prior high point during the evaluated path. |
| High-water mark | Highest recorded value reached during the job’s evaluated path. |
| Continuous-time Sharpe ratio | Risk-adjusted comparison aid; useful only with the evaluated period and assumptions attached. |
| Rolling position | How simulated exposure changed over time. |
| Trade count | Simulated trade or fill activity represented in the result. |
| Event count | Evaluation activity density across the historical range. |
| Data completeness | Whether the requested historical periods had enough available data for the intended evaluation. |
For the metric-level guide, read Backtest result metrics.
Data gaps and completeness
Section titled “Data gaps and completeness”Historical data coverage affects every backtest job.
When the requested range contains gaps, Structure surfaces data completeness so users can understand which parts of the requested period were evaluated. Complete segments and gaps belong with the result because a metric summary without data coverage can be misleading.
Use data completeness to answer:
- Which requested periods had available historical data?
- Which periods were excluded because data was unavailable?
- Which metrics came from complete segments?
- Which result comparisons use the same data coverage?
For assumption and coverage details, read Simulator assumptions and data completeness.
Comparing jobs and revisions
Section titled “Comparing jobs and revisions”Backtest comparison works best when each result keeps its assumptions attached.
Compare revisions across:
- Revision changes.
- Fixed node parameter changes.
- Strategy Variable values.
- Historical time range.
- Starting balances.
- Fees.
- Slippage.
- Latency.
- Liquidity assumptions.
- Data completeness.
- Metrics and position behavior.
A stronger metric summary only matters in context. Assumptions, data coverage, instrument behavior, and user risk tolerance affect the promotion decision.
Promotion boundary
Section titled “Promotion boundary”A backtest job does not become a live deployment by itself.
Promotion is an explicit user action. The user selects the tested revision, Strategy Variable values, connected account, venue context, permissions, and deployment settings for live operation.
The promotion boundary matters because backtest jobs use historical data and simulated execution. Live deployments use live market data and a live exchange gateway.
Interpretation limits
Section titled “Interpretation limits”Use backtest jobs as evaluation evidence, not as performance guarantees.
Backtest job results are conditional on:
- Historical data quality and coverage.
- Strategy Variable values.
- Starting balances.
- Fees.
- Slippage.
- Latency.
- Liquidity assumptions.
- Venue Simulator behavior.
- The current limitation that the Venue Simulator does not model the full exchange order book.
For the shared simulated execution model, read Venue Simulator methodology.