Simulator and evidence
Venue Simulator methodology
The Venue Simulator is the simulated execution destination used by paper deployments and backtest jobs.
It receives order activity from the Target Position Executor and records simulated fills, simulated account state, and result telemetry under explicit assumptions.
The Venue Simulator is an evaluation tool. It does not predict live fills, guarantee execution quality, or model the full exchange order book.
For the detailed assumption and data coverage guide, see Simulator assumptions and data completeness.
- Market data Live or historical market data sources.
- Venue Simulator Simulated execution destination and assumptions.
- Results Recorded metrics, telemetry, and review context.
- Paper path Long-running paper deployment boundary.
- Backtest path Finite backtest job boundary.
- Run settings Run-provided values, balances, ranges, or assumptions.
Where the Venue Simulator appears
Section titled “Where the Venue Simulator appears”The Venue Simulator is shared by two paths.
| Path | Data source | Execution destination |
|---|---|---|
| Paper deployment | Live market data server | Venue Simulator |
| Backtest job | Historical market data server | Venue Simulator |
Live deployments do not use the Venue Simulator. They send order activity to the live exchange gateway. Paper deployments and backtest jobs use the simulator to evaluate the selected revision and the current Target Position Executor path without sending order messages to a live venue.
What the simulator receives
Section titled “What the simulator receives”The simulator receives order activity from the Target Position Executor after the strategy engine emits target positions.
Conceptually, the input context includes:
- Selected strategy revision.
- Strategy Variable values for the run.
- Revision-owned venue and instrument.
- Target-position updates.
- Order activity generated by the Target Position Executor.
- Starting balances or simulated account state.
- Fees.
- Slippage.
- Latency.
- Liquidity assumptions.
- Historical or live market data context, depending on the path.
The simulator records simulated account and result context so users can review what happened under those assumptions.
For the execution boundary before simulated execution, see Target-position execution model.
Assumption summary
Section titled “Assumption summary”Simulator-backed results depend on the recorded assumptions.
| Assumption | 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 the observed market data context. |
| Latency | Changes timing between market data, target-position changes, order activity, and fills. |
| Fill model | Determines how simulated order activity becomes simulated fills. |
| Liquidity assumptions | Affects whether simulated order activity can be evaluated against available market context. |
| Data completeness | Shows whether the requested historical range had enough data for interpretation. |
Simulated account state
Section titled “Simulated account state”The Venue Simulator records simulated account state for paper deployments and backtest jobs.
Simulated account state can include:
- Simulated balances.
- Simulated positions.
- Simulated fills.
- Simulated order state.
- Result telemetry under recorded assumptions.
This state is useful for evaluation, but it is not the same as live venue account state. Live deployments use the live exchange gateway and connected venue account; paper deployments and backtest jobs use the Venue Simulator.
Fill model
Section titled “Fill model”The fill model determines how simulated order activity becomes simulated fills.
Structure exposes the fill model as part of the assumptions attached to a paper deployment or backtest job result. Review it alongside fees, slippage, latency, liquidity assumptions, and data completeness.
Because simulator settings affect results, compare only results whose assumptions are visible and understood.
Slippage
Section titled “Slippage”Slippage settings adjust simulated execution away from the observed market data context.
Use slippage settings to evaluate how a strategy behaves when simulated fills are less favorable than the visible reference price. Higher or lower slippage settings change result interpretation and comparison.
Fee settings apply cost assumptions to simulated order activity.
Fees affect PnL, drawdown, trade-level interpretation, and revision comparison. Keep fee settings visible when comparing backtest jobs or paper deployment results.
Latency
Section titled “Latency”Latency settings represent delay assumptions applied during simulated evaluation.
Latency can change the relationship between target-position changes, order activity, market data, and simulated fills. Review latency settings when interpreting position behavior, fills, and metric differences across runs.
Liquidity assumptions
Section titled “Liquidity assumptions”Liquidity assumptions describe how much simulated order activity can be evaluated against available market context.
These assumptions affect result quality, especially for strategies with larger target positions, frequent order activity, or instruments with changing liquidity conditions.
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 a live venue’s order book can include depth, queue position, cancellations, partial fills, changing spread, and other microstructure effects that simulated execution does not fully reproduce.
Do not read simulator-backed results as predictions of live fills. Treat them as evidence under the assumptions recorded with the result.
Comparing simulator settings
Section titled “Comparing simulator settings”When comparing results, keep simulator settings attached to the metrics.
Example comparison:
| Run | Slippage | Fees | Latency | Liquidity assumption | Interpretation |
|---|---|---|---|---|---|
| Backtest job A | Lower | Standard | Lower | Baseline | Shows behavior under less conservative assumptions. |
| Backtest job B | Higher | Standard | Higher | Baseline | Tests the same revision under more conservative execution assumptions. |
| Backtest job C | Higher | Higher | Higher | Reduced | Tests whether the revision remains acceptable when multiple assumptions are less favorable. |
The comparison is useful because the settings are visible. A single result without assumptions is not enough to interpret the strategy.
For a more complete comparison workflow, see Simulator assumptions and data completeness.
Result interpretation
Section titled “Result interpretation”Simulator-backed results are conditional on:
- Market data coverage.
- Strategy Variable values.
- Target-position behavior.
- Starting balances or simulated account state.
- Fees.
- Slippage.
- Latency.
- Liquidity assumptions.
- Fill model.
- The current limitation that the simulator does not model the full exchange order book.