Skip to main content
A data gap is any condition where the payload is not safe enough for the job: missing records, stale ingestion, partial coverage, known incidents, replay gap events, or a route-family mismatch that makes the output misleading. The correct response is not to hide the gap. A downstream system should know whether data was complete, delayed, degraded, or rejected. To decide whether data should be available before a job runs, start with Data availability.

​
Gap Types

​
Required Handling

1

Check before the job

Use data-quality routes or a bounded probe before backtests, alerts, dashboards, exports, or model jobs.
2

Propagate the result

Store freshness, incident, coverage, and request-ID context with the downstream output.
3

Fail visibly

If the gap matters for the job, mark the output incomplete or stop instead of filling silently.
4

Resume with an explicit policy

For replay or historical pulls, resume from a known safe checkpoint, not from whatever local state remains.

​
When Gaps Matter Most

Gaps matter most when output becomes evidence: backtests, trading research, strategy comparisons, risk models, alerts, customer dashboards, exports, and automated agent decisions. A stale latest quote may be acceptable for a UI smoke test and unacceptable for an alert. The job has to define the tolerance. For HIP-4, a price interpretation mistake can look like a data gap because probability-like values are being treated as USD prices. For HIP-3, a stripped builder prefix can send a request to the wrong family. For Spot, a pair-shaped symbol should stay under the Spot route family when the prompt asks for Spot.

​
Gap Decision Checklist

When a gap appears, store the decision instead of hiding it in logs.

​
Next Step

Use Data quality for the gate, Reliability and gaps for workflow design, and WebSocket backtesting when replay events feed research.
Last modified on June 28, 2026