Simulator and evidence
Backtest result metrics
A completed backtest job records metrics together with the context that produced them. Metrics are only meaningful when the selected revision, historical time range, Strategy Variable values, starting balances, simulator assumptions, and data completeness remain attached.
Backtest metrics are evaluation evidence under recorded assumptions. They are not performance guarantees and do not predict live deployment results.
How to read result metrics
Section titled “How to read result metrics”Read metrics as a group, not as isolated numbers.
For example:
- PnL without fees, slippage, latency, and data coverage can be misleading.
- A strong Sharpe-style metric with low event count may not be robust.
- Low drawdown under incomplete data may not describe the period you intended to test.
- Trade count and event count help explain whether the result came from frequent activity or a small number of events.
The result surface should answer two questions at the same time:
- What happened under the recorded settings?
- Are those settings complete and relevant enough for the comparison you want to make?
PnL summarizes profit and loss over the backtest job.
When reviewing PnL, keep these inputs visible:
- Historical time range.
- Starting balances.
- Fees.
- Slippage.
- Latency.
- Venue Simulator assumptions.
- Data completeness.
PnL is most useful when compared across jobs that keep the same baseline assumptions or deliberately change one assumption at a time.
Max drawdown
Section titled “Max drawdown”Max drawdown describes the largest decline from a prior high point during the evaluated period.
It helps users understand downside behavior under the recorded assumptions. A lower drawdown can be useful, but it should still be interpreted with historical data coverage, liquidity assumptions, and the selected revision’s target-position behavior.
High-water mark
Section titled “High-water mark”The high-water mark is the highest recorded value reached during the job’s evaluated path.
It is useful context for drawdown because drawdown is measured relative to prior highs. Review the high-water mark alongside the time range and position behavior to understand when the result reached its strongest point.
Continuous-time Sharpe ratio
Section titled “Continuous-time Sharpe ratio”The continuous-time Sharpe ratio is a risk-adjusted performance metric surfaced by Structure for completed backtest jobs.
Use it as a comparison aid, not as a standalone decision rule. Its interpretation depends on the evaluated period, data completeness, volatility of the result path, assumptions used by the Venue Simulator, and whether the compared jobs share the same context.
Rolling position
Section titled “Rolling position”Rolling position shows how the simulated position changed through the evaluated period.
This is often one of the most useful diagnostic views because it connects strategy behavior to exposure:
- Did the revision move toward the expected target positions?
- Did exposure change when the state machine changed intent?
- Did fees, slippage, latency, or liquidity assumptions affect position behavior?
- Did the strategy spend more time exposed than expected?
Review rolling position together with target-position behavior and event count.
Trade count
Section titled “Trade count”Trade count records the number of simulated trades or fills represented in the result surface.
Trade count helps explain activity level and cost sensitivity. A result with many trades may be more sensitive to fees, slippage, latency, and fill model assumptions than a result with few trades.
Event count
Section titled “Event count”Event count records how much evaluation activity occurred during the job.
Event count is useful for understanding the density of the evaluation. It can help identify whether a result came from a broad set of evaluated updates or a small number of events in the selected historical range.
Data completeness
Section titled “Data completeness”Data completeness describes whether Structure had the historical data needed for the requested range.
Completeness belongs next to every metric. If the requested range contains gaps, the result should be interpreted as a result for the available complete segments, not as a complete statement about the entire requested period.
For details, see Simulator assumptions and data completeness.
Comparison workflow
Section titled “Comparison workflow”When comparing backtest jobs, keep the comparison narrow:
- Compare the same revision with different Strategy Variable values.
- Compare two revisions over the same time range and assumptions.
- Compare one assumption change at a time, such as higher slippage or higher latency.
- Avoid ranking jobs by a single metric without reviewing the recorded context.
A better result is only meaningful when the assumptions, data coverage, instrument behavior, and user risk tolerance make the comparison relevant.