Loading…
DATA INTEGRITY
Corrections
When something in the data plane was wrong, it's disclosed here — what was affected, what we found, and what we did about it. This is not a security-incident log; see /responsible-disclosure and /trust for that.
Three incidents are disclosed below, all from the same evening during the intelligence platform's initial build-out. We're not aware of any other data-quality incident affecting the institutional data plane as of this page's last update.
Corrections
Event catalog was missing all live events
Detected: 2026-08-29Affected: the event catalog and every market/outcome derived from itThe primary event crawl paged the source's event list from oldest to newest on a fixed time budget and had never reached the live tail — roughly 1,946 live events existed only as catalog-less market rows, which broke volume aggregation and "live" filtering across the catalog.
Fix: Added an independent live-tail traversal with its own cursor, run alongside the original crawl.
Recomputed: yes. Backfilled through the standard sync path the same session — roughly 700 live events, 6,200 linked markets, and 12,400 outcomes — and catalog coverage has continued to grow via the regular sync since.
Live-event sync silently restarted from the beginning on every run
Detected: 2026-08-29Affected: live-tail catalog sync bookkeeping (cursor persistence only)A database constraint rejected the sync job's own bookkeeping row for this crawl type, so no cursor was ever saved — every scheduled run restarted the crawl from the top instead of resuming where the last one left off, wasting crawl capacity.
Fix: Widened the constraint to admit the new sync-run type; cursor now persists correctly between runs.
Recompute: not needed. All writes from the crawl are idempotent, so no incorrect data was ever recorded — only capacity was wasted.
A new signal type was rejected by its own database constraint
Detected: 2026-08-29, before the affected detector ran against live dataAffected: none — caught by an automated test before deploymentA newly added signal-detector output type would have been rejected by a database constraint that hadn't yet been updated to admit it. An automated contract check caught the mismatch before this code path ever ran in production.
Fix: Widened the constraint in the same change that added the new signal type.
Recompute: not applicable — zero rows were ever affected.
How we handle a wrong result
A mapping or computed value found to be wrong is marked withdrawn, not silently deleted or replaced. Any data derived from it is recomputed and the correction is disclosed here, with what changed and why — never applied quietly.