BTC Horizon
Experimental public beta · Probabilities are model outputs, not financial advice or trading signals.
← All research guides
BTC Horizon research guide

A missed forecast is part of the evidence: the October 14 incident

An original BTC Horizon operations case study: a SQLite lock, a missing private forecast, and why late reconstruction must stay out of forward scores.

Published by · BTC Horizon

5 minute read

What actually happened

On October 14, 2026 at 00:07:02 UTC, BTC Horizon’s private adaptive 24-hour shadow model failed while inserting a forecast. Its persisted run recorded SQLite error 5, “database is locked”. Nine of ten configured shadow forecasts completed; this one did not. The public CMC edition was a separate publication and was healthy during the investigation.

The evidence for this account is the project’s persisted generation-run error, operations incident history and recovery record. Those private operations records are summarised here; this article does not present an independently audited incident report or expose subscriber data.

Why a short database conflict lasted all day

The main SQLite connection used deferred transactions. Under WAL mode, a transaction that has already read may fail when it tries to upgrade to a writer after another connection has written. Waiting longer is not always enough to rescue that transaction’s earlier snapshot.

The generator ran once daily, recorded the failed run and continued with other models. The operations monitor correctly found an incomplete edition, but reminders every two hours added noise without retrying generation. A transient write conflict therefore became an unresolved publication gap.

What changed, and what recovery does not prove

The correction reserves the write lock at transaction start, allows up to five publication transaction attempts, and schedules idempotent generation attempts at 00:07, 00:08 and 00:09 UTC. Completed editions are retained. Unchanged critical incidents now receive a daily reminder; new incidents and recoveries remain distinct events.

The missing record was reconstructed at 22:43:06 UTC on October 14, 81,786 seconds after its scheduled midnight timestamp. Its actual publication time is recorded, and it is marked invalid with the reason delayed_publication. It cannot be treated as a prediction that existed before the intervening market moves.

Automated tests checked late-publication exclusion and repeat-generation behaviour. These changes address the observed failure mode; they do not establish that outages or lock contention can never recur.

The methodological lesson

A forecast reconstructed after the fact can help diagnose a system, but including it in a forward score would change the evidence. BTC Horizon invalidates shadow editions published more than 15 minutes after the scheduled timestamp. The deadline is an operational rule, not a statistical guarantee.

Readers should ask whether a track record preserves missed publications, source failures and invalid outcomes. Operational reliability and prediction quality are different questions. A healthy database does not validate a model, and an accurate reconstructed value does not repair a missed live prediction.

Methods and evidence

These notes explain BTC Horizon’s implementation and evaluation rules. Worked examples are illustrative unless explicitly described as observed records. Articles are prepared with AI assistance using the project’s code and documented records; they are not independent peer review.