A dashboard can display every expected feed and still be unready for comparison. The distinction becomes visible when one source is developing, or when a cached observation belongs to the wrong completed interval.
A 4/4 badge answers a coverage question. It cannot establish that four observations satisfy the snapshot policy.
Declare the required slots first
This example uses two fictional instruments and two timeframes. Each required slot has a symbol, a timeframe and an expected completed close time. A caller provides that plan. The evaluator does not infer exchange sessions or decide which candle should be complete.
Daily and four-hour observations need not have equal close timestamps. They need to match their respective expected slots in the same declared plan. Comparing all timestamps for equality would reject legitimate multi-timeframe snapshots.
const daily = Date.parse("2026-10-11T00:00:00Z");
const fourHour = Date.parse("2026-10-11T20:00:00Z");
const plan = ["VENUE:A", "VENUE:B"].flatMap(symbol => [
{ symbol, timeframe: "D", expectedClose: daily },
{ symbol, timeframe: "4H", expectedClose: fourHour }
]);
These timestamps are synthetic fixtures, not an exchange calendar or live market observation.
Keep coverage, confirmation and alignment separate
The evaluator returns a reason along with the state. An unrelated row cannot replace a missing required slot, and a duplicate cannot increase coverage. Strict boolean confirmation avoids accepting a truthy string such as "false".
// Educational contract, synthetic inputs; not a production trading engine.
function assessSnapshot(plan, rows) {
const waiting = reason => ({ state: 'WAIT', reason });
const key = x => JSON.stringify([x.symbol, x.timeframe]);
const validKey = x => x && typeof x.symbol === 'string' && x.symbol.trim()
&& typeof x.timeframe === 'string' && x.timeframe.trim();
const validClose = x => Number.isSafeInteger(x) && x >= 0;
if (!Array.isArray(plan) || !plan.length || !Array.isArray(rows)) {
return waiting('INVALID_CONTRACT');
}
const expected = new Map();
for (const slot of plan) {
if (!validKey(slot) || !validClose(slot.expectedClose) || expected.has(key(slot))) {
return waiting('INVALID_CONTRACT');
}
expected.set(key(slot), slot.expectedClose);
}
const observed = new Map();
for (const row of rows) {
if (!validKey(row)) return waiting('INVALID_ROW');
const id = key(row);
if (!expected.has(id)) continue; // unrelated data does not fill required slots
if (observed.has(id)) return waiting('DUPLICATE_SLOT');
observed.set(id, row);
}
const coverage = { present: observed.size, required: expected.size };
if (observed.size !== expected.size) return { ...waiting('INCOMPLETE_COVERAGE'), coverage };
for (const row of observed.values()) {
if (row.confirmed !== true) return { ...waiting('UNCONFIRMED_SOURCE'), coverage };
}
for (const [id, row] of observed) {
if (!validClose(row.closeTime)) return { ...waiting('INVALID_CLOSE_TIME'), coverage };
if (row.closeTime !== expected.get(id)) {
return { ...waiting('SNAPSHOT_MISMATCH'), coverage };
}
}
return { state: 'REVIEW_READY', reason: 'CONTRACT_MET', coverage };
}
The order of checks is deliberate: validate the contract and identities; establish required coverage; check confirmation; then compare completed close slots. Only after those checks does the example produce REVIEW_READY. That label means the illustrative data contract passed. It does not mean a trading candidate qualified.
Reproduce the full-coverage failure
const rows = plan.map(p => ({
symbol: p.symbol, timeframe: p.timeframe,
closeTime: p.expectedClose, confirmed: true
}));
// One row belongs to an earlier four-hour slot.
rows[3].closeTime -= 4 * 3600000;
console.log(assessSnapshot(plan, rows));
// { state: "WAIT", reason: "SNAPSHOT_MISMATCH",
// coverage: { present: 4, required: 4 } }
This is a useful UI boundary: keep the coverage badge and show the waiting reason beside it. Do not recolor the whole panel as ready merely because the count reached four.
Tests that exercise the boundary
13 local contract tests were run, including:
- distinct Daily/4H close times satisfying one plan;
- full coverage with a mismatched completed interval;
- unconfirmed data and the string
"true"instead of a boolean; - missing slots, duplicate observations and unrelated instruments;
- empty plans, duplicated expected slots, invalid close values and null rows;
- preservation of the input arrays.
All 13 passed for this small JavaScript function. That result does not validate an actual market feed, a paid indicator, exchange-session scheduling or browser performance.
Boundaries worth keeping explicit
The upstream producer must establish correct session calendars and expected closes. The row identity uses exact supplied identifiers; it does not normalize symbol aliases or resolve continuous-futures adjustments. Unknown extra instruments are ignored, but a malformed row fails explicitly. The returned reason is the first blocker encountered in the check sequence; a production diagnostic view may need a complete issue list.
This example has no price ranking, persistence threshold, liquidity model or order execution. A production system needs its own domain-specific gates, source provenance and failure handling.
Where the design question came from
The creator-owned Smart Swap and HOLD guide shows a real historical panel with complete coverage and pending time alignment. The confirmation-timing guide explains the separate clocks of chart and higher-timeframe sources. Both are useful interface examples; this function is an independent teaching exercise, not their internal implementation.
Disclosure: Trading Suite is an AGProLabs product. This article and illustrative code were prepared by an AI agent for AGProLabs; the contract was checked and the listed local tests were executed during preparation. These are creator-owned project references, not an independent review. The example is analytical education, not financial advice or a promise of results.
Top comments (0)