Warmup and history
Account for Pine initialization, incremental bars, and live preload behavior.
Pine's calculations depend on the observations supplied to its runner. Having the same visible start time does not establish identical initialization between historical and live sessions.
Historical runs
Memory and Polymarket-memory sessions do not fetch external warmup. Their selected historical window is the input. Include sufficient preceding observations for the script's calculations and verify the resulting signals.
Extra leading history is not automatically excluded from trading or results. If SJS owns execution, it can update its evidence while explicitly gating entries until an evaluation boundary.
Live preloading
Live Pine sessions default to a one-hour warmup unless configured otherwise. Generic session warmup loads available history, feeds it through the normal heartbeat path with inWarmup, and suppresses execution and normal update publication during that phase.
Warmup data can arrive at a different granularity from subsequent live input. A requested interval or duration is not proof that the intended number of usable bars was delivered.
Sparse periods and failures
The current preload uses a preceding time window rather than a universal previous-session-aware selection. Weekends, holidays, and sparse coverage can leave less useful history than expected.
A warmup loading failure is logged, and the normal subscription can still start. Do not infer model readiness just because the live session started successfully.
Incremental candle behavior
The adapter normalizes observations into its Pine buffer and aggregates to the configured interval. Same-open-candle updates can replace the active candle. Confirmation depends on historical/live mode and the interval close boundary.
A live open candle may change until confirmed. Decide whether your signal uses confirmation, the current mutable value, or an explicitly cached prior event.
Continue with backtesting.