Detrás de cámaras
Cómo está construida la infraestructura de datos y matching de Aclara tu voto. Esta sección es para desarrolladores e investigadores. Si buscas la explicación en lenguaje simple, ve a Metodología.
Stack tecnológico
Frontend
Next.js 16 (App Router) · Tailwind CSS · TypeScript
Desplegado en Vercel. Build estático con SSG para páginas de candidatos.
Backend
FastAPI · Python 3.11 · Pydantic
Desplegado en Railway. REST API con /questions, /quiz/submit, /candidates/full.
Datos
JSON canónico (candidates_canonical.json)
Single source of truth. Curado manualmente. Leído en startup por el backend.
Proxy
Next.js rewrites → /api/backend/:path*
El frontend proxea al backend. Elimina CORS en producción.
Flujo de producción actual
Algoritmo de afinidad
Cada pregunta está asociada a un eje temático y tiene un peso (1–3). Las respuestas se promedian ponderadamente por eje, resultando en un puntaje de usuario por tema en escala 1–5.
Cada candidato tiene un stance_score por tema (1–5). La afinidad en un tema se calcula como:
El puntaje final es la suma ponderada del acuerdo en cada tema multiplicada por el peso relativo del tema. Temas sin datos redistribuyen su peso proporcionalmente entre los temas disponibles.
Las preguntas con dirección negativa tienen sus respuestas invertidas antes del cálculo: 6 − respuesta.
Los 7 ejes temáticos
Los pesos reflejan la importancia relativa de cada tema en el perfil político colombiano 2026.
Seguridad
25%Política de paz, relaciones con grupos armados, fuerzas militares.
Economía
20%Modelo económico, inversión privada, rol del Estado en la economía.
Salud
15%Sistema de salud, EPS vs. modelo público, reforma a la salud.
Energía y Medio Ambiente
15%Transición energética, exploración de petróleo, acción climática.
Política Fiscal
10%Deuda pública, gasto social, reforma tributaria, austeridad.
Política Exterior
10%Relaciones con EE.UU., Venezuela, organismos internacionales.
Anticorrupción
5%Transparencia, control institucional, mecanismos anticorrupción.
Arquitectura de agentes
El sistema utiliza un pipeline de curación manual con dos agentes en producción. Los perfiles de candidatos son revisados y aprobados por humanos antes de publicarse — ningún cambio llega a los datos activos sin revisión explícita.
Review Agent
ActivoCompara el perfil propuesto con el publicado y genera un diff legible por humanos. Permite a un revisor aceptar o rechazar cambios antes de que lleguen a la data canónica.
Matcher Agent
ActivoLee el perfil canónico y las respuestas del usuario al quiz. Calcula afinidad usando promedios ponderados y normalización de escala. Explica los mayores acuerdos y divergencias.
Capa de revisión humana
Antes de que cualquier cambio generado automáticamente llegue a los datos publicados, pasa por una etapa de revisión explícita. El modelo de datos separa claramente:
Publicado
candidates_canonical.json
Datos activos. Curados manualmente. Lo que ve el usuario.
Propuesto
proposed_updates.json
Cambios sugeridos por el agente investigador. Pendientes de revisión.
Revisado
review_log.json
Decisiones del revisor humano: aprobado, rechazado, con notas.
Por qué datos estáticos primero
Confiabilidad ante todo. Un sistema de scraping automatizado comete errores — extrae posturas equivocadas, cita fuentes de baja calidad, o malinterpreta contexto político. Preferimos comenzar con datos curados (aunque pocos) antes que datos abundantes pero ruidosos.
Cero costo. No se usan APIs de búsqueda de pago ni servicios cloud. Todo corre estáticamente. El equipo puede desplegar y operar sin presupuesto.
Transparencia auditora. Cada dato tiene su fuente documentada en el JSON canónico. Cualquier persona puede revisar, cuestionar y proponer correcciones.
Escalabilidad gradual. La arquitectura está lista para agentes de investigación automáticos. Cuando el pipeline esté calibrado y validado, pasará a producción sin cambiar la capa de datos canónica ni el quiz.
Fotos de candidatos: Wikimedia Commons (CC BY-SA)