DATA INTEGRITY
Corrections
When something in the data layer was wrong, it is 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 and security for that.
Three incidents are disclosed below, all from the same evening during the intelligence platform's initial build-out. We are not aware of any other data-quality incident affecting the institutional data layer as of this page's last update.
Disclosed data-quality incidents
| Detected | Affected | Impact | Fix | Recompute |
|---|---|---|---|---|
| 2026-08-29 | The event catalog and every market and outcome derived from it. | Event catalog was missing all live events Data — incomplete catalog The 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. | Added an independent live-tail traversal with its own cursor, run alongside the original crawl. | Yes. Backfilled through the standard sync path the same session — roughly 700 live events, 6,200 linked markets and 12,400 outcomes — and coverage has grown through the regular sync since. |
| 2026-08-29 | Live-tail catalog sync bookkeeping only (cursor persistence). | Live-event sync silently restarted from the beginning on every run Capacity, not data 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 stopped, wasting crawl capacity. No published figure was wrong. | Widened the constraint to admit the new sync-run type; the cursor now persists between runs. | Not needed. Every write from the crawl is idempotent, so no incorrect data was ever recorded. |
| 2026-08-29 | None — caught by an automated test before deployment. | A new signal type was rejected by its own database constraint Near miss — caught by a test, no data affected A newly added signal-detector output type would have been rejected by a database constraint that had not yet been updated to admit it. An automated contract check caught the mismatch before this code path ever ran in production. | Widened the constraint in the same change that added the new signal type. | Not applicable. Zero rows were ever affected. |
Last updated · 2026-09-02
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.
Ask us about anything here
Every incident above is described in more detail to organizations with an Institutional Evaluation or Institutional plan, including the exact change that fixed it.