Skip to main content
Use this workflow to turn Polaris historical data into chronological model inputs and evaluate a trading rule without using future information. The complete example uses the Python SDK and hourly bars, while the same data surfaces are available in TypeScript and Rust.
This example is a research baseline, not a production trading strategy. A credible backtest must model the costs, latency, liquidity, funding, and data gaps that apply to its intended market and execution venue.

Choose the data your model needs

Start with the narrowest dataset that matches the model. Add execution-level or order-book data only when the hypothesis depends on intrabar behavior. Use ohlcv for bar-based signals. Use trades, bbo, or depth_metrics when fill quality and market impact affect the result. Use replay when the model must process mixed events in their stored order.

Install the Python dependencies

Install the DataFrame extra with the numerical packages used below:

Build a reproducible dataset

Resolve the exact source and market through Catalog, then choose explicit boundaries inside its published coverage. Fixed boundaries make repeated runs comparable and prevent the SDK’s recent-data default from moving over time.
asfreq(interval) makes missing intervals explicit. Do not forward-fill prices before calculating returns: that would hide gaps and create artificial observations.

Run a no-lookahead baseline

The following long-or-flat moving-average model calculates its signal at one bar close and shifts the position by one row. The return for a bar therefore uses only information available at the previous close.
cost_bps is charged whenever the target position changes. Replace this flat assumption with observed BBO spreads, depth metrics, fees, and venue-specific funding before using the result for a trading decision.

Evaluate out of sample

Keep model selection and evaluation separate. The example uses the first 70% of rows as an in-sample period and reserves the remaining 30% for evaluation.
The zero-rate Sharpe ratio is a compact diagnostic, not a complete assessment. Also inspect exposure, turnover, tail losses, parameter stability, and results across multiple markets and non-overlapping time periods.

Add execution realism

For large event-driven tests, consume iterator or Arrow-batch output instead of loading the complete range into memory. Keep the resolved source, market, Catalog bounds, model parameters, cost assumptions, and SDK version with every result so another researcher can reproduce it.