TL;DR
Data quality determines model quality. The current public contract proves exchange/feed metadata plus derived snapshot features, and confidence should drop when data integrity degrades.
Clear explanation
The current canonical SNAP payload records source metadata such as exchange and feed alongside derived feature values.
Every source has failure modes such as stale updates, symbol mismatches, and venue outages.
Syntalium validates feed freshness and consistency before producing state outputs, but the public site should not overstate that contract as full depth-of-book coverage.
Technical example: validation before scoring
An exchange feed degrades during an outage. Validation flags suppress aggressive model reactions.
- 01Measure freshness and sequence continuity.
- 02Detect latency spikes and data gaps.
- 03Apply confidence penalties.
- 04Store flags in SNAP payload for audit.
ASCII model
Exchange OHLCV/feed metadata --> Data validation --> Feature engine --> SNAP payload
Latency + gaps ------> Confidence penaltiesSource classes and controls
| Source class | Key risk | Control |
|---|---|---|
| Exchange/feed metadata | Wrong venue or stale feed | Canonical source fields + freshness checks |
| Derived feature values | Schema drift | Canonical feature order + hash verification |
| Runtime health flags | Silent degradation | Guardrails + published context |
Related pages
- Market Status model →See how data quality affects state confidence.
- Verification workflow →Validate source-informed snapshots with SHA256.
- What is SNAP →Data quality context is captured in hash-verifiable snapshots.
- Market Score concept note →Future methodology note only. It is not a live SignalX field.
FAQ
Why not use one exchange only?
Single-source pipelines are fragile during local outages and anomalies.
Do delayed feeds distort models?
Yes. Stale data can create false transitions and poor risk decisions.
Should on-chain data be included?
It can be useful for context, but it is not part of the current public hourly BTC contract.