Simulator and evidence
Simulator assumptions and data completeness
Paper deployments and backtest jobs use the Venue Simulator as their execution destination. Simulator-backed results are useful only when the assumptions and data coverage are visible.
These results are evidence under explicit assumptions. They do not predict live fills, guarantee returns, guarantee risk reduction, or guarantee live execution quality.
- Market data Live or historical market data sources.
- 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.
- Paper path Long-running paper deployment boundary.
- Backtest path Finite backtest job boundary.
- Revision-owned Immutable strategy revision logic and settings.
- Run settings Run-provided values, balances, ranges, or assumptions.
Assumption groups
Section titled “Assumption groups”Simulator-backed evaluation depends on several groups of assumptions:
| Assumption group | Why it matters |
|---|---|
| Starting balances or simulated account state | Defines the initial capital and exposure context. |
| Fees | Affects PnL, drawdown, and cost sensitivity. |
| Slippage | Adjusts simulated execution away from visible reference prices. |
| Latency | Changes the relationship between market data, target-position changes, and simulated fills. |
| Fill model | Determines how order activity becomes simulated fills. |
| Liquidity assumptions | Describes how much simulated order activity can be evaluated against available market context. |
| Data completeness | Shows which requested historical periods were available for evaluation. |
Review assumptions before comparing jobs or promoting a revision toward live operation.
Starting balances and simulated account state
Section titled “Starting balances and simulated account state”Starting balances define the simulated account state at the beginning of a backtest job. For paper deployments, simulated account state may be selected or initialized when the deployment starts.
This context affects position sizing, margin behavior where modeled, PnL, and drawdown. A result from one starting balance should not be compared casually with a result from a different starting balance.
Fee assumptions apply costs to simulated trading activity.
Fees can materially affect strategies with frequent order activity. When comparing results, keep fee settings visible and avoid comparing a low-fee result against a high-fee result unless fee sensitivity is the purpose of the comparison.
Slippage
Section titled “Slippage”Slippage assumptions make simulated execution less or more favorable relative to the observed market data context.
Higher slippage can test whether a strategy remains acceptable under less favorable execution. Lower slippage can show behavior under less conservative assumptions. Neither setting guarantees what a live venue will do.
Latency
Section titled “Latency”Latency assumptions represent delay during simulated evaluation.
Latency can affect when target-position changes turn into simulated order activity and fills. This is especially important for strategies that react frequently or operate in fast-moving markets.
Fill model and liquidity assumptions
Section titled “Fill model and liquidity assumptions”The fill model determines how simulated order activity becomes simulated fills. Liquidity assumptions describe how much simulated order activity can be evaluated against available market context.
These assumptions are central to result interpretation. They can affect:
- Whether simulated order activity fills.
- How position changes over time.
- PnL and drawdown.
- Trade count.
- Sensitivity to larger target positions.
Current order-book limitation
Section titled “Current order-book limitation”The current Venue Simulator does not model the full exchange order book.
That limitation matters because live venue behavior can include depth, spread changes, queue position, cancellations, partial fills, rejected orders, and other microstructure effects. Simulator-backed results should not be read as predictions of live fills.
Historical data completeness
Section titled “Historical data completeness”Historical data coverage affects every backtest job.
When the requested range contains gaps, Structure surfaces data completeness so users can see which parts of the requested period were evaluated. 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 results use the same coverage?
- Whether a comparison is based on equivalent data.
Complete segments and gaps
Section titled “Complete segments and gaps”Complete segments are the portions of the requested range that had enough available data for evaluation. Gaps are portions where required data was unavailable.
If two jobs have different complete segments, their metrics may not be directly comparable even if the selected revision and Strategy Variable values are similar.
Comparison rules
Section titled “Comparison rules”Use these rules when comparing simulator-backed results:
- Keep the selected revision attached to each result.
- Keep Strategy Variable values attached.
- Compare over the same historical range when possible.
- Compare with the same starting balances when possible.
- Keep fees, slippage, latency, fill model, and liquidity assumptions visible.
- Check data completeness before ranking metrics.
- Treat a single changed assumption as a sensitivity test, not as a guaranteed future outcome.