Semana 38: el detector congelado no corrió — su código no llegó byte-exacto al sandbox. El marcador sigue en 0/0.
TL;DR (válido al 2026-09-14). Semana 2026-W38: el detector congelado no corrió y el marcador prospectivo no avanzó — sigue en 0 de 0 (abierto en 2026-W37). El motivo es de infraestructura, no del modelo: el sandbox de cómputo de esta semana no pudo obtener el código fuente congelado del detector byte-exacto. Seis de los siete archivos se reprodujeron exactos; el séptimo (engine.py) llegó por la capa de transporte de archivos con un artefacto de un byte, y el snapshot direccionado por contenido que existe justamente para evitar esto se entregó por el mismo canal con pérdida y también llegó corrupto. Por la regla del propio proyecto — si el modelo congelado no se puede verificar byte-exacto, no se hacen predicciones ciegas y se publica el fallo — no se corrió ciencia. El modelo en sí está verificado intacto: el hash de sus pesos más el manifiesto de código recomputa a 08ad337d exactamente. Es un fallo de entrega, no un cambio de modelo. La línea de retrospectiva ciega sigue en 0 de 1.
Qué pasó, exactamente
La rutina de los lunes empieza reconstruyendo el detector congelado y verificándolo contra su hash registrado antes de cualquier predicción. El detector se fija por contenido: sus pesos se guardan como números y sus siete archivos fuente por SHA-256. Esta semana el sandbox recomputó la definición del modelo y coincidió — el hash de pesos más manifiesto de código es 08ad337d…, idéntico al registrado en la congelación del 2026-09-07. Los pesos no derivaron; el modelo no cambió.
Lo que falló es más acotado y puramente mecánico. Para volver a correr el detector, el sandbox debe materializar los siete archivos fuente byte a byte. Seis lo hicieron. El séptimo, engine.py, llegó de forma consistente un byte más grande que el original congelado a través de la capa de transporte de documentos, y la diferencia es reproducible entre lecturas independientes. El snapshot direccionado por contenido que se introdujo tras la auditoría de 2026-W37 — hecho justo para este modo de fallo — no pudo rescatarlo, porque el propio snapshot se entrega por el mismo transporte, y su blob comprimido de los dos archivos más grandes llegó corrupto. Un espejo público de código trajo cinco de los archivos byte-exactos (y aportó el sexto esta semana) pero no contiene esta revisión de engine.py.
Qué sabemos y qué no
Sabemos: el modelo congelado está intacto (hash del manifiesto verificado); seis de siete archivos fuente son byte-exactos; el fallo es determinista y está en el transporte de archivos hacia el sandbox de cómputo, no en la ciencia. No sabemos — y no lo vamos a suponer — si correr el detector desde el archivo alterado en un byte habría producido predicciones idénticas. Lo no verificable es no verificable; no publicamos un acierto ni un fallo prospectivo que no podamos sostener.
Por qué publicamos una semana sin resultado
El marcador prospectivo vale algo solo porque se publica antes de conocer el resultado y solo cuando el detector que lo produjo es demostrablemente el congelado. Una semana que no pudimos verificar es en sí un dato sobre el proceso, y ocultarla derrotaría en silencio el propósito. Así que la semana queda registrada, el marcador se mantiene en vez de avanzar, y el arreglo queda nombrado: el código congelado debe llegar al sandbox por un canal byte-exacto — un checkout de git, que esta semana resultó byte-exacto — y no por el transporte de documentos.
Declaración de límite
Este reporte describe una caída de infraestructura en nuestro propio pipeline de medición. No hace ninguna afirmación, positiva ni negativa, sobre ninguna proteína, sitio o estructura. Nada aquí autoriza a nadie a considerar un sitio alostérico confirmado ni descartado. Nuestros negativos nunca autorizan a descartar un sitio; esta semana no hay siquiera negativos — solo una corrida que no ocurrió.