Warmup
תוכן זה אינו זמין עדיין בשפה שלך.
Warmup is the period at the start of every run during which indicators are calculating their first valid output and the strategy is settling into its operating state. Your strategy doesn’t need to handle warmup explicitly — the platform suppresses execute() until everything is ready — but understanding it helps reason about backtest start times and walk-forward boundaries.
Two flavors of warmup
| Flavor | Purpose | User-controlled? |
|---|---|---|
| Indicator warmup | Each indicator needs N bars before its math produces a valid value. |
Implicit — derived from period. |
| Strategy warmup (ADR-0160) | A settling lead-in where the strategy runs but its trades are recorded as warmup, never sent. | The deploy form’s “Strategy warmup” field (default 50). |
Where it applies today: the strategy-warmup phase runs on cloud runner deploys — warmup trades are recorded and flagged, never sent. Backtest and optimization requests still use the indicator floor only; their three-phase integration is a later ADR-0160 wave.
Indicator warmup
Every indicator declares the minimum bars it needs. The platform fetches that much history before your execute() runs:
SMA(20)→ 20 bars.RSI(14)→ 15 bars.MACD(12, 26, 9)→ 26 bars.
When a strategy uses multiple indicators, the warmup is the maximum across all of them. The platform auto-resolves this — you don’t compute it yourself.
By the time your first execute() is invoked, every indicator returns a valid value. You never see the “indicator is warming up” phase from inside the strategy.
Strategy warmup (three-phase model)
Some strategies benefit from a lead-in period beyond the indicator warmup — for example:
- Strategies with persistent state that needs to converge (counters, running statistics).
- Strategies tuned in optimization where the first few trades on a fresh state are atypical.
The three-phase model (ADR-0160) lets you declare this explicitly:
| Phase | OnBar | Trades | Duration |
|---|---|---|---|
| Phase 1 — Indicator warmup | Dormant | None | indicatorWarmupBars (auto) |
| Phase 2 — Strategy warmup | Runs | Recorded, flagged as warmup — never sent | strategyWarmupBars (user) |
| Phase 3 — Live | Runs | Real | Run length |
During Phase 2, execute() fires normally and signals are processed, but the resulting trades are
flagged as warmup and never reach a broker. The strategy “warms up” by running.
The phases are invisible to your code. There is deliberately no warmup flag on self — warmup
is a runner-lifecycle concept the platform owns, and your strategy runs the same logic in every
phase. (A strategy that behaved differently during warmup would produce live behavior no backtest
could reproduce — exactly the divergence RaamCode’s determinism guarantee exists to prevent.) The
engine handles all attribution: which fills are warmup-flagged, and what the Strategy Board shows.
Walk-forward and warmup
In walk-forward analysis, each window runs end-to-end as a separate “mini-run” — including its own warmup. The platform stitches windows with shadow fills: indicators continue to receive bars at window boundaries so they don’t restart from cold, but persistent state resets per window.
| Resets between WFA windows? |
|---|
| Indicators — No (shadow fills preserve state) |
| Persistent state — Yes (resets to zero values) |
| Position — Yes (each window starts flat) |
| Capital — Depends on sizing model (Compounding chains, others reset) |