Cómo auditamos tres errores reales al verificar el estado de Ormuz
Tres fallos reales, por qué ocurrieron, cómo se corrigieron y qué pruebas impiden que vuelvan a publicarse como hechos.
Por qué publicar una auditoría de errores
Un monitor automatizado puede fallar de formas que una noticia convencional no muestra: confundir el nombre de un medio, interpretar una pregunta como afirmación o conservar un estado antiguo cuando la prueba que lo sostenía ya no es válida. Documentar estos casos aporta más valor que fingir infalibilidad. Esta página resume tres controles construidos a partir de incidencias reales del proyecto.
Caso 1: un alias corto dentro de otra palabra
Una fuente oficial podía identificarse mediante el alias “ONA”. Si el programa buscaba esas letras como una subcadena, también aparecían dentro de “national”. El resultado potencial era atribuir un artículo de National Security Journal o The National Interest a Oman News Agency, elevando injustificadamente su nivel de autoridad.
Corrección aplicada: los alias cortos deben coincidir como palabras completas o mediante dominio verificado. Además, una contradicción entre el medio del titular y la fuente detectada deja de ser una simple advertencia.
Caso 2: una pregunta que contiene la palabra “open”
Un titular como “Why can’t X keep the Strait open?” incluye la palabra open, pero no afirma que el estrecho esté operativo. Es una pregunta analítica. Un clasificador basado únicamente en palabras clave puede producir un falso positivo.
Corrección aplicada: titulares interrogativos, de opinión o con fórmulas como “keeps insisting” no pueden confirmar apertura o cierre. Una descripción factual separada sí puede aportar evidencia si contiene una afirmación operativa explícita.
Caso 3: heredar una confirmación inválida
Aunque el clasificador se corrija, un estado publicado anteriormente puede persistir mediante una regla de continuidad. Si la última confirmación era inválida, el error se prolongaba sin una noticia nueva.
Corrección aplicada: cada ciclo revalida que la confirmación coincide con el estado, la señal, la fuente y la ventana temporal. Si no supera la prueba, el sistema rebaja el estado a INCIERTO en vez de conservar una certeza heredada.
| Riesgo | Prueba automática | Respuesta pública |
|---|---|---|
| Alias incrustado | “ona” no coincide dentro de “national”. | Fuente desconocida o no oficial hasta verificar dominio. |
| Titular interrogativo | No genera OPEN_OPERATIONAL ni CLOSED_OPERATIONAL. | Puede aparecer como contexto, no como confirmación. |
| Estado heredado sin respaldo | Se revalida en todos los ciclos. | Rebaja automática a INCIERTO. |
| Copias de una misma agencia | Se agrupan por origen/dominio. | No cuentan como fuentes independientes. |
Qué significa “revisión humana” en este proyecto
La automatización ejecuta consultas, normaliza fuentes y aplica reglas. La responsabilidad editorial humana consiste en definir umbrales, revisar falsos positivos, corregir atribuciones, documentar cambios y no ocultar incertidumbre. No implica que una persona apruebe manualmente cada ciclo horario; implica que las reglas y sus excepciones son auditables y corregibles.
Registro de cambios y reproducibilidad
El repositorio conserva pruebas y commits. El estado público expone fecha de comprobación, confianza, evidencias y última confirmación válida. La combinación permite reconstruir por qué se publicó una clasificación y detectar si una modificación posterior alteró el resultado.
Cómo se elaboró este análisis
- Autoría
- Equipo editorial de Estrecho Ormuz.
- Método
- Síntesis de fuentes primarias, comparación de magnitudes y cálculos propios claramente señalados.
- Revisión
- Revisión documental realizada el 4 de agosto de 2026. Se actualiza si cambian los datos fuente.
- Correcciones
- Política y registro de correcciones.