Casos

Un hallazgo que no sobrevivió a su propia auditoría

El Mundial 2026 en el tráfico aéreo · Observed State Index

Resumen

En julio de 2026 este sistema publicó un resultado limpio: durante el Mundial, las ocho ciudades sede subieron su tráfico aéreo y las cinco ciudades de control bajaron, sin una sola excepción, con una probabilidad de 1 en 1.287 de ocurrir por azar.

Este documento es la auditoría de ese resultado, hecha seis semanas después. La conclusión es que la tabla publicada no se puede reproducir a partir de los datos, por dos defectos que se acumularon exactamente sobre el periodo del torneo: la fuente perdió dos tercios de sus capturas, y el reloj con el que se clasificaban esas capturas estaba mal.

Recalculado con la hora real de captura, algo queda en pie: los cinco controles bajan y cinco de las ocho sedes suben. Pero la separación perfecta desaparece —Dallas y Atlanta caen por debajo de tres controles— y el p-valor pasa de 0,00078 a un rango de 0,011 a 0,045 según cómo se agregue.

El hallazgo, por tanto, no era falso. Era mucho menos seguro de lo que se afirmó, y se afirmó con una cifra que nunca se calculó sobre estos datos.

Qué se afirmó

El estudio original comparaba el periodo del torneo (11 de junio – 19 de julio de 2026) contra las seis semanas previas, sobre trece corredores aéreos: ocho en ciudades sede y cinco elegidos por no compartir región ni huso horario con ellas.

Reportaba Vancouver +26 puntos, Nueva York +15, Los Ángeles +15, Chicago +14, y las otras cuatro sedes en positivo; Sídney −30, Bangkok −20, Singapur −20, y los otros dos controles en negativo. De ahí, un test de Mann-Whitney con p = 0,00078.

Por qué se volvió a mirar

Por una nota en la documentación del propio sistema: entre el 6 de junio y el 26 de agosto de 2026, el proceso de captura de tráfico aéreo agotaba su tiempo a mitad de la lista de 30 nodos, moría, se reintentaba y volvía a empezar desde el principio, muriendo en el mismo punto.

El periodo del torneo cae entero dentro de esa ventana. El periodo de comparación, casi entero fuera:

VentanaFechasDías afectados
Seis semanas previas30-abr → 10-jun5 de 42
Torneo11-jun → 19-jul39 de 39

Comparar esas dos ventanas es comparar dos calidades de dato distintas. Eso bastaba para justificar la revisión; lo que apareció al hacerla fue peor.

Primer defecto: la cobertura se derrumbó

El identificador de cada nodo lleva prefijo numérico (001_ams, 002_atl, … 030_yvr), de modo que el orden alfabético es el orden en que el proceso los recorría. La pérdida sigue esa posición al pie de la letra:

NodoPos.Capturas antesCapturas torneoDías (de 39)
atl_atlanta00224721739
bkk_bangkok00323521339
dfw_dallas00820313139
gru_sao_paulo0121786918
jfk_new_york0161604814
lax_los_angeles0181513914
ord_chicago0231403013
syd_sydney0281273013
yvr_vancouver0301243714

Nueve de los trece nodos tienen datos de entre 13 y 18 días de los 39 que duró el torneo. Y qué días sobrevivieron no lo decidió nada relacionado con el Mundial: lo decidió hasta dónde alcanzaba a llegar el proceso antes de morir.

Un torneo medido un tercio de sus días no está mal medido. Está sin medir en dos tercios.

Segundo defecto: el reloj estaba mal

El sistema compara cada captura contra el historial de esa misma franja horaria, y en aquel momento la identidad de la franja se derivaba del número de secuencia de la corrida, no de la hora real de la captura. Ese defecto está documentado por separado; lo que no se había medido es cuánto afectó a este periodo concreto.

Se puede medir, cruzando el número de corrida contra la hora real que traen los datos crudos. Durante el torneo:

Corridafranja 1franja 2franja 3franja 4
0139000
02241500
03240150
04024312
0502421
0602402
0700223
0800222
0900221
1000022
1100022
1200022

El patrón real es de tríos por franja: las corridas 1 a 3 son la franja 1, las 4 a 6 la franja 2, las 7 a 9 la franja 3 y las 10 a 12 la franja 4 — porque cada franja se reintentaba tres veces antes de rendirse.

Un cálculo que asuma "corrida 3 = franja 3" acierta 15 de 39 veces. "Corrida 4 = franja 4", 12 de 39. Y las corridas de la 5 a la 12 no tienen ninguna franja que les corresponda bajo ese supuesto.

En total, en la ventana del torneo el 23% de las capturas habría recibido la etiqueta correcta. En la ventana de comparación, el 45%. Dos ventanas mal etiquetadas, con patrones de error distintos, comparadas entre sí.

El intento de reproducir la tabla

El estudio original dice comparar "el promedio de conteos diarios por nodo". Esa frase admite varias lecturas, así que se probaron cuatro, todas sobre los datos ya reconstruidos con la hora real:

Método¿Reproduce la tabla?
Media por captura, cambio %No — el signo coincide en 6 de 13, peor que el azar
Suma diaria, cambio %No
Media por captura, diferencia absolutaParcial — Vancouver da +25,2 contra los +26 publicados, pero Bangkok sale con el signo contrario
Franja contra franjaEl más cercano: el signo coincide en 11 de 13, pero las magnitudes no se parecen

Ninguno reproduce la tabla publicada. Y hay un detalle que descarta la explicación más cómoda: los métodos ingenuos ponen a tres ciudades sede en el fondo de la tabla —Atlanta −45,6%, Dallas −51,4%, Denver −35,5%—, porque al perderse sobre todo las franjas 3 y 4 (las de 14:30 y 19:30 UTC, las de más tráfico y por tanto más datos que descargar), la ventana del torneo quedó dominada por las franjas de madrugada, que en Norteamérica son las más vacías.

Es decir: el artefacto de cobertura no pudo fabricar el resultado publicado. Habría hecho lo contrario: destruirlo. Lo que quedaba por explicar era entonces de dónde salió esa tabla, y el reloj mal puesto es la única causa identificada capaz de producir una ordenación arbitraria sobre estos nodos.

El recálculo, con la hora real

Anclando cada captura a su hora real y comparando franja contra franja —que es como opera el sistema hoy—, con dos formas de agregar las cuatro franjas de cada nodo:

NodoGrupoMedia de %Panel equilibrado
yvr_vancouversede+9,9%+10,6%
den_denversede+2,2%+2,6%
mex_mexico_citysede−0,6%+1,3%
lax_los_angelessede+2,9%+1,2%
ord_chicagosede+3,2%0,0%
jfk_new_yorksede+0,7%−0,8%
sin_singaporecontrol−3,7%−5,2%
bkk_bangkokcontrol−4,1%−6,0%
gru_sao_paulocontrol−3,1%−6,7%
dfw_dallassede−4,8%−7,0%
atl_atlantasede+2,2%−7,7%
jnb_johannesburgcontrol−11,3%−8,8%
syd_sydneycontrol−7,2%−12,8%

Las dos columnas no son alternativas cosméticas. La primera promedia los cambios porcentuales de las cuatro franjas, lo que da a la franja 2 de Atlanta —30 aeronaves de media— el mismo peso que a su franja 3, que tiene 832. La segunda suma las cuatro medias de cada ventana y las compara, que equivale a preguntar cuánto cambió el ciclo completo de un día muestreado una vez por franja. La segunda es la defendible, y es la que mueve a Atlanta de +2,2% a −7,7%.

Los p-valores, calculados por enumeración exacta de las 1.287 particiones posibles y no por aproximación normal:

MétodoUp (1 cola)p (2 colas)Separación perfecta
Media de %30,00540,011No
Panel equilibrado60,02250,045No
Publicado00,00078

Y una observación sobre esa última fila: 0,00078 es exactamente 1/1.287, la probabilidad del único arreglo posible más extremo de los 1.287. No es un estadístico calculado sobre unos datos: es el p-valor que corresponde a la separación perfecta, sea cual sea la magnitud de los números. Al perderse la separación perfecta, esa cifra deja de tener referente.

Qué queda en pie y qué no

Se sostiene: los cinco controles bajaron, en las dos formas de agregar. Cinco de las ocho sedes subieron. La diferencia entre los dos grupos sigue siendo estadísticamente significativa al 5% en ambos estimadores, y la magnitud mayor sigue siendo la de Vancouver.

Hay un matiz a favor que conviene decir, porque va contra la conclusión de este documento: si el proceso moría con más facilidad en las capturas más pesadas, los días que sobrevivieron son los más tranquilos, y ese sesgo empuja a todos los nodos hacia abajo. La brecha real entre sedes y controles podría estar subestimada, no inflada.

No se sostiene: la separación perfecta, el "sin una sola excepción", la cifra 1 en 1.287 y las magnitudes publicadas. Dallas y Atlanta terminan por debajo de tres controles.

No se puede saber: de dónde salió exactamente la tabla original. El reloj mal puesto es la causa más probable y la única identificada, pero no se ha reconstruido el cálculo que la produjo.

Y hay un límite que ninguna corrección arregla: nueve de los trece nodos tienen medido un tercio del torneo. Ese dato no existe y no se puede recuperar; el torneo terminó y el defecto se corrigió después. Cualquier versión futura de este análisis parte de ahí.

Lo que este caso demuestra

Que un resultado limpio merece más desconfianza que uno sucio, no menos. La separación perfecta entre trece nodos era la razón por la que este hallazgo parecía sólido, y era en realidad la señal de que convenía mirarlo dos veces.

Que dos defectos que ya estaban documentados por separado —la pérdida de capturas y la franja derivada del número de corrida— no habían sido cruzados contra los análisis que dependían de ellos. Cada uno tenía su nota; ninguna nota decía qué conclusiones publicadas caían dentro de su periodo.

Que la auditoría es barata cuando el sistema guarda sus datos crudos. Todo lo de este documento salió de cuatro consultas sobre el mismo almacenamiento que alimenta el sitio, sin instrumentación nueva y sin volver a pedir un solo dato a la fuente.

Que corregir hacia abajo es parte del método. Un sistema que solo publica lo que confirma sus hallazgos no es un instrumento de medición: es un argumento.

Nota metodológica

El hallazgo del cierre de espacio aéreo del Golfo no está afectado por esto, y se comprobó en lugar de suponerlo. En su periodo (1 de enero – 5 de marzo de 2026) el número de corrida sí correspondía a la franja real: la corrida 1 acertó 64 de 64 veces, y las corridas 2, 3 y 4 acertaron 59 de 64 cada una. Los reintentos existían, pero eran ocasionales — 28 corridas extra en 64 días, frente a las 191 de la ventana del torneo.

Sí queda afectado el análisis de la recuperación posterior a aquel evento, que abarca de marzo a agosto de 2026 y por tanto entra en el periodo degradado. Por eso no se publica: está pendiente de recalcular.

Reproducibilidad

Los datos son los mismos que alimentan el sitio: capturas de adsb.lol almacenadas en formato columnar, consultadas con SQL estándar. Las cuatro consultas de esta auditoría son la tabla de cobertura por nodo y ventana, la distribución de franjas por nodo y ventana, el cruce de número de corrida contra hora real, y las medias por nodo y franja. La agregación posterior y el test exacto se hicieron sobre esas medias.

← Volver al índice

Esto mismo, una vez al día, en Telegram.

Este sitio no tiene publicidad, pero sí genera un costo.Si te resulta útil, puedes apoyarlo.