Add docs on choosing data and bars processing (#2195)

- Order of OHLC in bar processing
- Choosing data: cost vs. accuracy

docs/concepts/backtesting.md

@@ -84,6 +84,21 @@ available or necessary, then the platform has the capability of processing marke
 5. **Bars**:
    - Aggregating trading activity - typically over fixed time intervals, such as 1-minute, 1-hour, or 1-day.
 
+### Choosing data: Cost vs. Accuracy
+
+For many trading strategies, 1-minute bar data can be sufficient for backtesting and strategy development. This is
+particularly important because bar data is typically much more accessible and cost-effective compared to tick or order book data.
+
+Given this practical reality, Nautilus Trader is designed to handle bar-based backtesting with sophisticated features,
+that help maximize simulation accuracy while working with this lower granularity data.
+
+:::tip
+For some trading strategies, it can be practical to start development with bar data to validate core trading ideas.
+If the strategy looks promising, but is more sensitive to precise execution timing (e.g., requires fills at specific prices
+between OHLC levels, or uses tight take-profit/stop-loss levels), you can then invest in higher granularity data
+for more accurate validation.
+:::
+
 ## Venues
 
 When initializing a venue for backtesting, you must specify its internal order `book_type` for execution processing from the following options:
@@ -149,6 +164,34 @@ Even when you provide bar data, Nautilus maintains an internal order book for ea
    - For LIMIT orders working in the market, they'll execute if any of the bar's prices reach or cross your limit price (see below).
    - The matching engine continuously processes orders as OHLC prices move, rather than waiting for complete bars.
 
+#### OHLC prices simulation
+
+During backtest execution, each bar is converted into a sequence of four price points(O HLC). How these price points
+are sequenced can be controlled via the `bar_adaptive_high_low_ordering` parameter when configuring a venue.
+
+Nautilus supports 2 modes:
+
+1. **Fixed Ordering** (`bar_adaptive_high_low_ordering=False`, default)
+   - Processes every bar in fixed sequence: `Open → High → Low → Close`
+   - Simple and deterministic approach  
+2. **Adaptive Ordering** (`bar_adaptive_high_low_ordering=True`)
+   - Uses bar structure to estimate likely price path:
+   - If Open is closer to High: processes as `Open → High → Low → Close`
+   - If Open is closer to Low: processes as `Open → Low → High → Close`
+   - Testing shows this approach achieves 75-85% accuracy in predicting correct High/Low sequence (compared to statistical 50% accuracy with fixed ordering)
+   - This is particularly important, when both take-profit and stop-loss levels fall within the same bar - as the sequence determines which order is filled first
+
+Here's how to configure adaptive bar ordering for a venue:
+
+```python
+# Configure venue with adaptive bar ordering
+engine.add_venue(
+    venue=venue,
+    oms_type=OmsType.NETTING,
+    bar_adaptive_high_low_ordering=True,  # Enable adaptive ordering of High/Low in the bars
+)
+```
+
 ### Slippage and Spread Handling
 
 When backtesting with different types of data, Nautilus implements specific handling for slippage and spread simulation: