Market data and freshness
Validate observations, define your sampling rule, and avoid using stale or future evidence.
The current bar is the observation supplied to this strategy invocation. Its common fields are date, open, high, low, close, volume, and instrument, but individual fields can be absent. Validate the fields your decision actually uses.
For the full input workflow, see the Market Data guides: instrument identity, intervals, historical and live data, sessions, and readiness.
Define a sampling rule
The quickstart accepts finite numeric closes and valid timestamps. It records one close for each strictly increasing timestamp and ignores repeated or older timestamps. Its moving average therefore means “the last three accepted observations,” not automatically “the last three closed exchange candles.”
For a live bar that updates repeatedly under one timestamp, this code keeps the first valid close it sees. A live adaptation needs an explicit completed-bar or update policy. Changing that policy changes the strategy even if the average formula stays the same.
Missing data and gaps
The sample resets its window after a gap greater than maximumGapMs. With one-minute input and a two-minute limit, an overnight gap restarts warmup. It does not invent bars to fill missing periods.
Invalid observations do not advance its timestamp. A later valid observation can still be accepted, but the elapsed time since the previous valid observation may trigger a reset. This makes absent data visible as a new warmup period rather than an apparently continuous signal.
If you change the input interval, also revisit the gap limit and sample count. Three one-minute observations and three fifteen-minute observations represent different horizons.
Historical windows
context.historicalData(instrument, startDate, endDate, interval?, backfill?) provides a separate route for historical calculations. Anchor the end bound to bar.date when making a decision in replay; new Date() would describe the current wall clock instead.
Check that the returned data exists, has the expected ordering and coverage, and does not include timestamps beyond the decision time. Do not assume every provider uses the same interval spelling or inclusive-boundary convention. The chosen calculator or data adapter owns those details.
Fetching a window on every update can be expensive. The tutorial avoids external history calls by maintaining a bounded local window. A built-in calculator may use a different data source and warmup policy; see Indicators and algorithms.
Evidence from Pine or configured algorithms
An object being present is not proof of freshness. For a Pine point, compare its timestamp with the frame according to the producer's timestamp convention. For a configured model, use its documented readiness and time fields; there is no universal snapshot timestamp field shared by every algorithm.
The existing Pine-to-SJS tutorial demonstrates timestamp checks for chart points. Because native Pine runs after SJS in the shared runner, a strategy reading its output must define which completed observation it expects rather than assuming same-invocation availability.
Signal provenance
Keep a decision timestamp and the relevant evidence together. The quickstart's signal stores frame, side, close, and average, and copies that evidence into execution metadata. This lets you compare the request against the observation that caused it.