Week 38: the frozen detector did not run — its code could not reach the sandbox byte-exact. Scoreboard holds at 0/0.
TL;DR (valid as of 2026-09-14). Week 2026-W38: the frozen detector did not run and the prospective scoreboard did not advance — it holds at 0 of 0 (opened 2026-W37). The reason is infrastructure, not the model: this week's compute sandbox could not obtain the detector's frozen source code byte-exact. Six of the seven code files reproduced exactly; the seventh (engine.py) arrived through the file-transport layer with a one-byte artifact, and the content-addressed snapshot that exists precisely to prevent this was delivered through the same lossy channel and also arrived corrupted. By the project's own rule — if the frozen model cannot be verified byte-exact, no blind predictions are made and the failure is published — no science was run. The model itself is verified intact: its weights-plus-code manifest hash recomputes to 08ad337d exactly. This is a delivery failure, not a model change. Blind-retrospective line unchanged at 0 of 1.
What happened, exactly
The Monday routine begins by rebuilding the frozen detector and verifying it against its recorded hash before any prediction is made. The detector is pinned by content: its weights are stored as numbers and its seven source files by SHA-256. This week the sandbox recomputed the model definition and it matched — the weights-and-code-manifest hash is 08ad337d…, identical to the value recorded at freeze on 2026-09-07. The weights did not drift; the model did not change.
What failed is narrower and entirely mechanical. To re-run the detector the sandbox must materialise the seven source files byte-for-byte. Six did. The seventh, engine.py, consistently arrived one byte larger than the frozen original through the document-transport layer, and the difference is reproducible across independent reads. The content-addressed snapshot introduced after the 2026-W37 audit — built for exactly this failure mode — could not rescue it, because the snapshot itself is delivered through the same transport, and its compressed blob for the two largest files arrived corrupted. A public code mirror carried five of the files byte-exact (and supplied the sixth this week) but does not contain this revision of engine.py.
What we know and what we don't
We know: the frozen model is intact (manifest hash verified); six of seven source files are byte-exact; the failure is deterministic and located in file transport into the compute sandbox, not in the science. We don't know — and will not guess — whether running the detector from the one-byte-altered file would have produced identical predictions. Unverifiable is unverifiable; we do not publish a prospective hit or miss we cannot stand behind.
Why we publish a week with no result
The prospective scoreboard is worth something only because it is published before the outcome is known and only when the detector that produced it is provably the frozen one. A week we could not verify is itself a data point about the process, and hiding it would quietly defeat the point. So the week is logged, the scoreboard is held rather than advanced, and the fix is named: the frozen code must reach the sandbox through a byte-exact channel — a git checkout, which this week proved byte-exact — rather than through document transport.
Limit declaration
This report describes an infrastructure outage in our own measurement pipeline. It makes no claim, positive or negative, about any protein, site, or structure. Nothing here authorises anyone to consider any allosteric site confirmed or ruled out. Our negatives never license discarding a site; this week there are not even negatives — only a run that did not happen.