Cámara de Diputados: reconstruir votaciones nominales desde SITL
La Cámara de Diputados publica información suficiente para reconstruir una parte importante de su actividad parlamentaria, pero no la entrega como un dataset estable.
La fuente existe. Es pública. Tiene valor institucional. Pero no se comporta como una base de datos.
El trabajo de camara-diputados-mex parte de esa fricción: convertir el sistema SITL/INFOPAL en una base trazable de votaciones nominales. No por confianza ciega en el portal, sino por reconstrucción: descubrir periodos, localizar votaciones, seguir partidos, normalizar votos nominales, persistirlos en SQLite y auditar qué parte del resultado puede sostenerse contra la fuente original.
Esta página no es un manual de uso del repositorio. Es una lectura reconstructiva del proceso: cómo una publicación institucional diseñada para navegación humana se convierte en evidencia legislativa procesable.
| Fuente | Proceso | Persistencia | Auditoría | Estado |
|---|---|---|---|---|
| SITL/INFOPAL | Scrapy standalone | SQLite | contraste contra SITL | parcial / post-fix en validación |
El problema: una fuente oficial no es lo mismo que un dataset
SITL/INFOPAL expone páginas, tablas, enlaces y parámetros. Pero una publicación oficial no equivale automáticamente a un dataset.
Un dataset necesita estabilidad, campos reconocibles, reglas de identidad, trazabilidad y criterios de validación. La fuente institucional, en cambio, aparece como una combinación de HTML estático, rutas históricas, parámetros por legislatura, tablas de conteo, listados nominales y convenciones que cambian entre generaciones del portal.
La tarea no consiste entonces en “descargar datos”. Consiste en reconstruir una fuente.
Eso implica distinguir contenido sustantivo de navegación, separar evidencia directa de inferencias, contar ausencias y evitar que la limpieza de datos borre señales importantes sobre la fragilidad de la fuente original.
SITL/INFOPAL: HTML estático como fuente primaria
A diferencia de otros portales legislativos que dependen de vistas AJAX o respuestas fragmentadas, el caso de Diputados trabaja principalmente sobre HTML estático.
Esa estabilidad relativa no elimina el problema. Lo desplaza.
El reto no es atravesar una interfaz hostil en tiempo real, sino reconocer patrones históricos dentro de páginas que no fueron diseñadas como API: índices de periodos, listados de votaciones, tablas de conteo por partido y páginas nominales enlazadas por parámetros.
El scraper de camara-diputados-mex está implementado como un proyecto Scrapy standalone. Su flujo reconstruye la serie histórica de la LX a la LXVI Legislatura a partir de la propia estructura publicada por SITL/INFOPAL.
SITL/INFOPAL
│
├── periodos
├── votaciones
├── partidos
└── votos nominales
│
▼
SQLite auditadoDescubrimiento dinámico
Una de las decisiones centrales del proyecto es no tratar periodos, votaciones ni partidos como listas fijas.
El scraper descubre dinámicamente:
- periodos legislativos disponibles;
- votaciones dentro de cada periodo;
- partidos presentes en las tablas fuente;
- enlaces nominales asociados a cada votación y partido.
Esta decisión importa porque el portal no se comporta como una tabla histórica única. La estructura cambia entre legislaturas, las rutas no siempre tienen el mismo patrón y los identificadores solo son interpretables dentro de su contexto.
En una fuente institucional de larga duración, cada patrón estable importa. Pero ningún patrón debe elevarse a verdad global sin validación.
El P0 histórico: votaciont no era una clave global
El hallazgo más importante del proyecto fue un problema de identidad.
El parámetro votaciont parecía un identificador suficiente para una votación. Pero la serie histórica demostró otra cosa: votaciont es secuencial por legislatura.
Eso significa que un mismo número puede aparecer en más de una legislatura sin referirse al mismo acto legislativo. Tratarlo como clave global mezcla entidades históricas distintas.
La consecuencia es fuerte: la DB histórica previa queda inválida para análisis.
No se trata de un error cosmético. Es un problema en la identidad misma de las votaciones. Si la clave no distingue legislatura, el dataset puede sobrescribir, mezclar o atribuir registros nominales a un contexto legislativo incorrecto.
La corrección exigió claves compuestas con legislatura.
Antes:
votaciont
Después:
legislatura + votaciontEsta regla cambia la lectura del dataset. Una votación no es solo un número; es un número situado dentro de una legislatura.
Tres estados de la base
Para leer correctamente el proyecto conviene separar tres estados.
DB histórica inválida
La DB histórica es la base previa a la corrección del P0. Al tratar votaciont como si fuera globalmente único, no preserva adecuadamente la separación entre legislaturas.
No debe usarse como fuente válida para análisis histórico.
DB limpia auditada
La DB limpia auditada disponible es:
data/diputados_clean_20260429_143417.dbSobre este corte se consolidó una reconstrucción limpia y se ejecutó una auditoría contra SITL.
| Métrica | Valor en DB limpia auditada |
|---|---|
| Votaciones | 4,386 |
| Conteos por partido | 36,220 |
| Votos nominales | 2,173,969 |
| Diputados | 4,402 |
| Votaciones auditadas contra SITL | 35/35 PASS |
Estos números describen el estado de la DB limpia auditada. No deben leerse como una clausura total del proyecto ni como garantía automática sobre toda dimensión derivada.
DB derivada post-fix en curso
Después de la auditoría, ingeniería corrigió en código el tratamiento de diputados.entidad. Ese fix ya existe y fue commiteado localmente.
Pero la DB derivada post-fix todavía está en proceso de materialización y validación. Por eso, cualquier afirmación dependiente de esa base debe mantenerse condicionada.
El estado correcto de publicación es: parcial / en validación post-fix.
Auditoría: validar sin borrar la frontera
La auditoría de la DB limpia se hizo contra la fuente original SITL. En la muestra de votaciones auditadas, el resultado fue 35/35 PASS para votaciones, conteos y votos nominales.
Ese resultado sostiene la reconstrucción corregida de votaciones en la muestra auditada. Pero no convierte automáticamente todos los campos del proyecto en definitivos.
La distinción es importante: validar por dominios evita dos errores opuestos. Por un lado, evita descartar una base útil por un campo aún en corrección. Por otro, evita declarar victoria total solo porque las métricas principales de votaciones pasaron.
En este corte, la parte fuerte es la reconstrucción de votaciones, conteos partidistas y votos nominales en la DB limpia auditada. La parte que sigue condicionada es la materialización post-fix de campos territoriales asociados a diputados.
Territorio, suplentes y diputados.entidad
El campo diputados.entidad abrió una frontera distinta a la de las votaciones.
La regla metodológica vigente es que, para suplentes, la validación territorial debe hacerse contra el propietario. El territorio representado no se infiere únicamente del nombre que aparece en un registro, sino de la relación institucional con la curul.
Esta regla evita confundir origen personal, texto curricular o aparición nominal con representación territorial.
El fix de código busca que futuros datos no guarden bloques textuales, circunscripciones o valores nulos indebidos cuando existe una representación territorial interpretable. Pero hasta que la DB derivada post-fix cierre su validación, ese resultado no debe presentarse como materializado en una base final.
Decisión de schema: sin columna circunscripcion
El schema actual no agrega una columna separada circunscripcion.
Cuando la fuente expresa una circunscripción y no un distrito ordinario, la representación temporal es:
distrito = "Circ. N"Esta decisión mantiene compatibilidad con el modelo actual y conserva la señal de la fuente sin introducir todavía una columna cuya semántica histórica requeriría una decisión de schema más amplia.
No significa que una circunscripción sea equivalente a un distrito. Significa que, por ahora, el dataset preserva esa información dentro del campo disponible mientras la modelación futura se decide explícitamente.
Alcance: votaciones nominales
El foco de este corte es la reconstrucción histórica de votaciones, conteos por partido y votos nominales.
Las comisiones están fuera de alcance por decisión de Nolan. No se tratan como deuda del dataset ni como omisión pendiente de reparación.
Ampliar el alcance hacia comisiones implicaría otra pregunta, otro modelo y otra validación.
Garantías y límites
Garantías actuales
- El proyecto es un scraper Scrapy standalone para la Cámara de Diputados.
- La fuente primaria es SITL/INFOPAL.
- El alcance histórico trabajado cubre LX-LXVI.
- La extracción se basa en HTML estático y descubrimiento dinámico de periodos, votaciones y partidos.
- El P0 histórico de
votaciontfue corregido mediante claves compuestas conlegislatura. - La DB histórica previa queda inválida para análisis.
- La DB limpia auditada
data/diputados_clean_20260429_143417.dbcontiene 4,386 votaciones, 36,220 conteos por partido, 2,173,969 votos nominales y 4,402 diputados. - En la muestra auditada, 35/35 votaciones pasaron contra SITL.
Límites actuales
- La página describe un estado parcial, no una clausura final.
- La DB derivada post-fix sigue en curso de materialización y validación.
- El fix de
diputados.entidadexiste en código, pero no debe presentarse como ya materializado en una DB final validada. - Las afirmaciones territoriales deben respetar la regla de suplentes: validación contra propietario.
- El schema no incorpora columna
circunscripcion; usa temporalmentedistrito = "Circ. N". - Las
comisionesquedan fuera del alcance actual por decisión de Nolan.
La tesis operativa es simple: una fuente institucional se vuelve dataset cuando cada identificador se sitúa en su contexto, cada transformación deja rastro y cada frontera de validación se declara sin sobreactuarla.