Procesar 34,117 actas E-14 del escrutinio Senado 2026 en 6 minutos: el pipeline técnico de CASTOR

13 de mayo de 2026 · 9 min de lectura · Por CASTOR Elecciones

Subes la foto o PDF del acta E-14 de tu mesa. En menos de 60 segundos vas a saber: si los números cuadran, si falta alguna firma, si hay sumatorias inconsistentes, y a qué causal del Código Electoral corresponde si encontramos algo. Este post explica qué pasa cuando tú entras — y debajo, como respaldo, el detalle del pipeline técnico que procesó 34.117 actas del escrutinio Senado 2026 en 6 minutos.

Lo que tú haces en 3 pasos

1. Subes el acta E-14 de tu mesa. Foto del celular o PDF descargado del portal de la Registraduría. Importa menos la calidad de lo que crees — el sistema audita y verifica.
2. Esperas menos de 60 segundos. El OCR pasa, un LLM auditor verifica cada número transcrito, cuatro niveles de validación aritmética cruzan totales E-11, E-14 y registros oficiales.
3. Recibes el diagnóstico. Datos extraídos línea por línea, validación aritmética con flag exacto en sumatorias que no cuadran, alertas de los siete focos de riesgo si aplican, y si hay irregularidad seria — el escrito de denuncia o demanda Art. 139 CPACA con la causal del Código Electoral citada.

Eso es lo que vives tú. El resto del post es el respaldo técnico de por qué eso funciona a escala — la prueba de que el pipeline detrás no es un script ad hoc, sino infraestructura que ya corrió en producción sobre el escrutinio Senado 2026 completo.

Las cifras del corte (la prueba de capacidad)

El corte representa el 55.77% del escrutinio nacional al 8 de mayo de 2026. El pipeline es reproducible: cada nuevo corte se procesa en el mismo orden de magnitud de tiempo, sin intervención manual.

El pipeline de extremo a extremo

API Registraduría
    ↓
Extracción burst async (httpx + retries + rate limiting)
    ↓
Normalización (campos opcionales · 4 ingestores tolerantes)
    ↓
Clasificación por mesa (BUENA / REVISAR / MALA)
    ↓
Cálculo de share local + concentración Pareto
    ↓
SQLite (32,656 mesas) + JSON store (TTL en memoria)
    ↓
API REST 15+ endpoints
    ↓
Dashboard Streamlit + Web · Charts interactivos

Las fases siguientes describen cada bloque con el detalle suficiente para que un equipo técnico pueda evaluar la robustez del sistema.

Fase 1 · Extracción del API

El API público de resultados electorales de la Registraduría Nacional del Estado Civil expone los datos del escrutinio en bloques que combinan metadatos de mesa (departamento, municipio, puesto, número de mesa, jurado, fecha) y datos numéricos (votos por candidato, totales, blancos, nulos, no marcados). El extractor de CASTOR opera con tres principios:

• Concurrencia asíncrona con httpx: hasta diez workers en paralelo controlados por un rate limiter para no saturar el backend de la Registraduría ni disparar bloqueos.
• Retries con backoff exponencial: cada request falla suave hasta tres intentos. El extractor diferencia entre errores transitorios (timeout, 503) y errores definitivos (404 de mesa no publicada todavía).
• Resolución de CAPTCHA opcional: para endpoints que requieren verificación humana, el extractor integra un solver externo (2Captcha) activable por configuración. Para el escrutinio Senado 2026, la captura primaria no requirió CAPTCHA en el flujo automatizable.

El tiempo total del extractor para los 34,117 registros del corte fue del orden de minutos, no horas. Esto importa porque permite re-correr el pipeline completo cada vez que la Registraduría actualiza el porcentaje del cómputo nacional, no esperar al cierre.

Fase 2 · Normalización tolerante a versiones

Los campos del API pueden cambiar entre ciclos electorales — nombres, tipos, codificaciones de partidos, formato de fechas. Una arquitectura rígida se rompe en el primer cambio de esquema. La normalización de CASTOR usa cuatro ingestores tolerantes y un modelo Pydantic con campos opcionales:

1. Ingestor de metadatos de mesa — extrae departamento, municipio, puesto, mesa, fecha, jurado. Acepta variaciones en nombres de campo y aplica codificación DANE como pivote canónico.
2. Ingestor de candidatos / partidos — extrae el listado de fuerzas políticas y sus votos. Tolera adiciones y eliminaciones de partidos sin romper el flujo.
3. Ingestor de agregados de mesa — total votos, blancos, nulos, no marcados, total sufragantes E-11. Valida coherencia aritmética al final.
4. Ingestor de marcadores de calidad — flags de captura (acta con firma, datos completos, errores OCR reportados por la Registraduría). Cada marcador alimenta la clasificación de Fase 3.

El resultado de esta fase es un registro canónico por mesa, con tipos de datos estables y campos opcionales explícitos. Esto permite que un cambio de esquema del API no rompa el pipeline — solo deja vacíos campos opcionales que el clasificador y el dashboard manejan grácilmente.

Fase 3 · Clasificación por mesa

Cada mesa procesada recibe dos clasificaciones independientes:

Clasificación operativa — refleja la calidad del dato capturado:

• BUENA: datos completos, sumatorias consistentes, firma de jurado presente, sin marcadores de error.
• REVISAR: datos incompletos, alguna inconsistencia menor o marcador de OCR cuestionable que requiere validación humana.
• MALA: votación marginal (share del segmento monitoreado bajo 1%) o captura inválida (total_votes = -1).

Clasificación estratégica — sirve para asignar presupuesto de campaña:

• Fidelizado: share local consistente y alto sostenido entre cortes.
• De opinión / activable: volumen alto y share medio — voto convertible.
• Pasivo: share menor a 1% en mesa de bajo volumen.

El detalle conceptual de ambas clasificaciones está en las guías de voto de opinión vs voto fidelizado y de causales RJ-01 a RJ-06.

Fase 4 · Persistencia híbrida

El sistema usa dos capas de almacenamiento con responsabilidades distintas:

• SQLite para el set canónico de mesas (32,656 registros del corte). Ventaja: archivo único, fácil de versionar, queries SQL contra un set finito sin necesidad de servidor de base de datos.
• JSON store en memoria con TTL de 5 minutos para resultados intermedios y consultas frecuentes del dashboard. Dedup por SHA-256 del payload para evitar duplicados de extracciones encimadas.

La combinación significa que el sistema corre completamente sin infraestructura externa para el caso del corte. Cuando se agrega histórico (Senado 2022, Presidencial 2022, regionales 2023), se promueve a PostgreSQL, pero el flujo del corte actual sigue siendo SQLite + JSON in-memory.

Fase 5 · API REST y dashboards

El backend expone más de quince endpoints REST que sirven como interfaz canónica entre el pipeline y los consumidores (dashboard web, dashboard Streamlit, reportes, integraciones de terceros). Endpoints clave:

Los dashboards consumen estos endpoints y agregan visualización. El sistema entrega doce charts interactivos: KPIs nacionales, ranking por volumen, ranking por intensidad, matriz volumen × intensidad, curva Pareto de concentración, distribución por departamento, distribución regional, mapa de calor por municipio, ranking de prioridad, escenarios de variación, segmentación y casos atípicos.

Por qué el tiempo importa menos que la reproducibilidad

Procesar 34,117 actas en seis minutos es noticia, pero no es lo más importante. Lo crítico es que el pipeline es reproducible: cada nuevo corte del escrutinio se procesa con el mismo flujo, sin intervención manual, con el mismo esquema de salida.

Una campaña presidencial no usa un análisis hecho una vez al final del escrutinio — necesita el dashboard recalculado semanalmente entre cortes, idealmente diariamente cerca del día E. Un pipeline manual no escala a esa cadencia. Un pipeline automatizado sí.

Robustez del sistema en producción

Algunos detalles operativos que importan cuando este tipo de pipeline corre cerca del día E:

• Backup local de PDFs originales: el sistema conserva una copia local de las actas E-14 PDF descargadas. Si la Registraduría desactiva el endpoint público después del cierre, el set local sigue siendo procesable. Para el escrutinio Senado 2026, se backup-eó priorizadamente el subconjunto top Pareto (mesas que concentran el 80% del voto del segmento monitoreado).
• Tolerancia a corte parcial: el sistema funciona con cualquier porcentaje del escrutinio nacional. Las cifras presentadas se marcan explícitamente como cortes parciales y se recalculan automáticamente cuando llega más data.
• Cookie / OAuth de fallback: si el método primario de autenticación contra el backend de la Registraduría falla, hay un mecanismo OAuth alternativo. La extracción no depende de un único punto de fallo.
• Schema robusto: campos opcionales con valores por defecto razonables. Cambios menores en el API del proveedor no rompen el pipeline.

Qué falta y qué viene

El pipeline actual cubre el corte parcial del escrutinio en producción. Las extensiones priorizadas para el ciclo presidencial 2026 son:

• Choropleth con códigos DANE oficiales: el mapa de calor por municipio actualmente es placeholder; integrar GeoJSON DANE permite el mapa real.
• Histórico Senado 2022 + Presidencial 2022 + regionales 2023: para construir un modelo predictivo y comparar contra el ciclo actual.
• Errores aritméticos por mesa desagregados: la Registraduría reporta 31,164 errores aritméticos a nivel agregado nacional sin desglose por mesa; extraerlos por mesa permite auditoría forense fina.
• Cálculo de participación / abstención usando el censo electoral oficial por municipio.
• Análisis competitivo multi-partido: hoy el pipeline analiza una fuerza específica; extenderlo a todas las fuerzas habilita comparación cruzada.

Cada extensión requiere ingestión adicional pero no cambia la columna vertebral del pipeline. La arquitectura está diseñada para crecer en superficie sin refactor.

El stack en una línea

Python 3.10+ con Flask 3.0 (monolito en puerto 5001), httpx async para extracción, Pydantic para normalización, SQLite + Redis para persistencia, Azure OCR custom como servicio primario (con LLM auditor) y Tesseract como fallback legacy. Frontend en Jinja2 templates más vanilla JS con Chart.js y Leaflet para visualizaciones, dashboard secundario en Streamlit. JWT para auth en endpoints protegidos.

Detalles del stack actualizado en el repositorio interno del proyecto. El sistema entero corre sin Docker en desarrollo local — el store en memoria evita la necesidad de infraestructura externa para el caso del corte.

El insight final

Procesar el escrutinio E-14 colombiano en minutos no es un fin en sí mismo. Es la precondición para que cualquier persona — un ciudadano con la foto de su acta, un testigo electoral, un abogado constitucionalista, un comité jurídico de campaña — pueda decidir con datos en lugar de con intuición, dentro de los 30 días que da el Art. 164 CPACA para radicar una demanda de nulidad.

La diferencia entre un análisis hecho a mano una vez y un pipeline reproducible no es velocidad: es democratización. Cuando procesar una acta cuesta 60 segundos y USD 5, la auditoría electoral deja de ser un privilegio de campañas grandes con presupuesto de inteligencia. Cualquier ciudadano puede activar la misma capacidad sobre su propia mesa.