← PoliScore · Investigaciones sobre Chile Anexo · Observatorio Político

Metodología

PoliScore busca ser un índice transparente y reproducible. Esta página describe cómo se construye el puntaje y qué representa.

Versión de metodología vigente: 2026.09.5 · motor 1.0.0. Cada cifra publicada lleva este número; los cambios se fechan en Cambios de metodología.

Principio

PoliScore no realiza valoraciones editoriales sobre personas, partidos o instituciones. La plataforma presenta datos, cálculos derivados y fuentes verificables. No se afirma que una figura sea «buena», «mala», «mejor», «peor», «favorable» o «desfavorable»; cuando aparece una etiqueta de ese tipo es porque la usa explícitamente una fuente citada, y se atribuye a esa fuente.

Qué es y qué no es

Un puntaje no se publica cuando la cobertura no cumple los requisitos mínimos de esta metodología: en ese caso se informa «Datos Insuficientes» o «Datos No Disponibles» y nunca se rellena con un valor neutro (ni 0 ni 50).

REAL BETA: qué datos usa el sitio

El sitio público funciona en REAL BETA (DATA_MODE=real) y usa únicamente:

Una figura sin cobertura real suficiente aparece como Datos Insuficientes: no recibe puntaje y no se rellena con 0 ni con 50. Hoy solo el Presidente cumple los mínimos para un PoliScore General; otras figuras muestran solo las métricas reales disponibles (por ejemplo, evaluación de figura de la CEP).

Existe además una base de datos simulados (poliscore.db) que se usó para desarrollar y probar el motor. No alimenta ninguna página pública; se mantiene solo para las pruebas automatizadas.

Preparación y datos insuficientes

Cada figura tiene un nivel de Preparación (0–100) que combina el número de mediciones, el número de encuestadoras distintas, la actualidad de la última medición y la diversidad de métricas. No mide desempeño: mide cuánta evidencia real hay disponible.

Un índice se publica solo cuando se cumplen sus mínimos (por ejemplo, aprobación presidencial: ≥ 3 mediciones de ≥ 2 encuestadoras dentro de la ventana de 45 días). Si no, el índice queda como «Datos Insuficientes» y se explica por qué.

Actividad institucional

La actividad institucional describe actividad observable y no implica una evaluación de calidad, eficacia o mérito. Incluye asistencia, sesiones, votaciones, intervenciones, proyectos presentados o patrocinados y participación en comisiones, tomados de fuentes oficiales (Senado, Cámara de Diputadas y Diputados, BCN, Presidencia). Estos registros se muestran tal cual; no se convierten en un puntaje ni alimentan el PoliScore General. La ausencia de datos no se interpreta como ausencia de actividad.

Política de fuentes

Preservación de fuentes

Cada URL citada se archiva al momento de usarla: una copia local de los bytes originales (PDF exacto o HTML comprimido) como evidencia primaria, y —cuando es posible— un snapshot en la Wayback Machine. Si un medio edita o retira una nota después, la afirmación de PoliScore sigue verificable. La copia local no se publica: la API expone solo la URL original, el hash del contenido, la fecha de captura, la URL archivada y el estado de preservación. No se sortean muros de pago, logins, CAPTCHA ni restricciones de robots.txt.

Noticias y eventos

PoliScore no opina sobre las noticias. Registra el titular, el medio, la fecha y el enlace original, y agrupa las publicaciones que cubren el mismo hecho. No se clasifica una noticia como positiva o negativa.

Qué hechos entran

Un hecho se incluye solo si cumple todas estas condiciones, no por su relevancia percibida ni por el volumen de cobertura:

La ausencia de una noticia no significa que el hecho no ocurrió: significa que todavía no se ha verificado contra una fuente admisible. No se seleccionan hechos para favorecer ni perjudicar a nadie, y la lista de fuentes admitidas es pública (más abajo). La verificación de enlaces y de los controles metodológicos se repite de forma automática cada semana (scripts/weekly_audit.sh); el detalle está en /internal/news-audit.

Un hecho = un evento

20 artículos sobre el mismo hecho son 1 evento con source_count = 20, no 20 eventos. El número de fuentes es una señal de relevancia, nunca un multiplicador de impacto. La agrupación (cluster_key) es determinista: misma figura + misma fecha del hecho + firma del titular normalizado; además se fusionan artículos del mismo día y figura con titular muy similar (Jaccard ≥ 0.55) o con titular y descripción similares. Ante la duda no se fusiona: es preferible tener dos eventos que un impacto duplicado. El comando python -m app.ingest_news dedup lista los pares candidatos a fusión para revisión manual. La identidad de un artículo se calcula sobre la URL canónica (sin utm_*, sin #fragmento, sin variante /amp, sin www.), de modo que dos enlaces al mismo recurso cuentan una sola vez.

Tres tipos de fuente

TipoQué esEjemplos
Fuente oficialpublicación del propio órgano del Estado Presidencia, Senado, Cámara de Diputadas y Diputados, Servel
Fuente primariadocumento fuente verificable, no periodístico LeyChile / BCN, Diario Oficial, sentencias
Fuente periodísticamedio de comunicación que reporta el hecho Emol, La Tercera, BioBioChile, CIPER, T13

Una nota periodística no equivale a una fuente oficial. Un evento se marca VERIFICADO solo si tiene al menos un artículo verificado proveniente de una fuente oficial o primaria.

Efecto sobre el puntaje

Las noticias reales viven en una base propia (poliscore_news.db), separada de las encuestas. Ninguna noticia modifica un puntaje automáticamente: el feed de Noticias es descriptivo y trazable. Si no hay ninguna noticia verificada cargada, la página lo dice explícitamente y no muestra nada simulado.

Registro verificable (Dicho vs. Hecho)

El Registro pone en una sola línea de tiempo, por figura, dos cosas: lo que dijo (declaraciones públicas) y lo que hizo (hechos verificados y actividad institucional). El orden es estrictamente cronológico; se puede filtrar por tema.

Qué hace y qué no hace PoliScore aquí

El Congreso

El Congreso lista a diputadas, diputados, senadoras y senadores en ejercicio y su actividad, tomados directamente de las fuentes oficiales:

Cada registro guarda la URL exacta de la consulta oficial y la fecha en que se obtuvo. La actividad parlamentaria es descriptiva (qué se registró) y no alimenta ningún puntaje: actividad no es lo mismo que desempeño.

«Por verificar»

Los conteos agregados (p. ej. «450 votaciones emitidas en 2026») provienen de la API oficial pero PoliScore todavía no ha auditado sesión por sesión. Se muestran igual —la fuente es oficial y cualquiera puede recontar desde la misma URL— con la etiqueta POR VERIFICAR. Cuando PoliScore completa la auditoría, la etiqueta desaparece. «DATOS NO DISPONIBLES» significa que esa actividad aún no se ha sincronizado, no que la persona esté inactiva.

Análisis electoral y parlamentario

Para cada parlamentario, dos bloques: cómo fue elegido (resultados oficiales de SERVEL) y actividad parlamentaria (Cámara / Senado). Todo es descriptivo y no modifica el PoliScore General. Sin dato oficial verificable: DATOS NO DISPONIBLES — nunca 0, 50 ni «estimado».

Distrito y comunas

Cada diputado se muestra con su distrito, su región y su período. Las comunas del distrito se toman de la columna comuna de los archivos oficiales de SERVEL y se muestran en un detalle desplegable; no se infiere ninguna asociación comuna–distrito. Los senadores conservan su circunscripción y región y no tienen número de distrito.

Sistema D'Hondt

Las elecciones parlamentarias chilenas (Ley 18.700) reparten los escaños de cada territorio entre las listas con el método D'Hondt, y luego, dentro de cada lista, los escaños van a los candidatos con más votos personales.

D'Hondt: para cada lista se calculan los cocientes votos/1, votos/2, votos/3, … Se ordenan todos los cocientes de mayor a menor y los N mayores (siendo N los escaños del territorio) reciben un escaño. PoliScore guarda el cálculo completo —cada cociente, su divisor y su rango— para que cualquiera lo verifique a mano (Ver cálculo D'Hondt en la ficha). El cociente D'Hondt no es un recuento de votos.

Margen de asignación D'Hondt

Diferencia entre el último cociente que obtuvo escaño y el primer cociente que quedó fuera. Describe la distancia matemática a la frontera de asignación. No es «ventaja» ni «beneficio».

Votos para cambiar un escaño (contrafactual)

Ejecutando D'Hondt repetidamente sobre los resultados oficiales, con los votos de las demás listas constantes, PoliScore calcula el mínimo cambio de votos de una lista que le habría dado un escaño más, o que le habría hecho perder su último escaño. Es una simulación sobre resultados oficiales, no una predicción electoral.

Efecto de asignación (Top-N)

Compara el resultado real con un escenario Top-N: si el territorio elige N parlamentarios, entran simplemente los N candidatos con más votos personales, sin importar la lista. La diferencia es +1 (electo con el sistema real y no bajo Top-N), 0 (igual) o −1 (no electo con el sistema real y sí bajo Top-N). El escenario Top-N es un contrafactual descriptivo y no representa un sistema electoral vigente. No se usa «beneficiado» ni «perjudicado».

Métodos proporcionales alternativos

Con los mismos votos y escaños, PoliScore muestra también la distribución por lista bajo Sainte-Laguë (divisores 1, 3, 5, …) y Hare / restos mayores. Simulación contrafactual: no representa el sistema electoral vigente ni una estimación de intención de voto. Los escaños alternativos no se trasladan a candidatos.

Asistencia y votaciones

Asistencia lista a diputadas, diputados, senadoras y senadores con datos disponibles. La asistencia real (presente / justificado / sin justificar sobre el total oficial de sesiones de cada período) se toma de la API oficial de sesiones del Senado — el mismo cálculo que el Senado ya publica, sin reconstrucción desde actas crudas. La Cámara de Diputadas y Diputados no tiene todavía una fuente equivalente sincronizable y se muestra como tal, nunca aproximada. Las ausencias justificadas se muestran separadas de las demás; Sala y Comisión nunca se mezclan en un único porcentaje. En votaciones se cuenta participación, a favor / en contra / abstención / pareo según las categorías oficiales; PoliScore no calcula alineamiento ideológico ni etiqueta coherencia.

Umbrales visuales (color por rango)

En la ficha de cada parlamentario y en el resumen por Cámara, el porcentaje de asistencia se acompaña de un color — rojo, ámbar o verde — según en qué rango numérico cae:

Estos umbrales (75% y 90%) son una convención de lectura definida por PoliScore para que el número se distinga de un vistazo — no una calificación, una nota ni un juicio de desempeño del parlamentario. El color nunca reemplaza el dato: junto a cada color siempre se muestra el porcentaje exacto y la fracción de sesiones (p. ej. «181 / 250 sesiones»), nunca una palabra como «buena», «mala», «deficiente» o «excelente». El resto de las dimensiones (gastos, votaciones, proyectos, comisiones, cobertura) usan barras y gráficas de evolución solo para facilitar la lectura de cantidades — sin colores de rango, porque PoliScore no ha definido (ni define) un umbral de «bueno o malo» para ellas.

Gastos y asignaciones parlamentarias

Gastos y asignaciones muestra gasto operacional, personal de apoyo, asesorías externas y viajes nacionales, tomados de la API oficial de transparencia activa del Senado. Es una dimensión informativa: no implica eficiencia ni ineficiencia y no modifica ningún puntaje; las comparaciones entre parlamentarios son cifras objetivas de la misma cámara y período. La Cámara de Diputadas y Diputados publica estos mismos conceptos sin API ni datos abiertos equivalentes, así que queda PENDIENTE hasta encontrar un camino automatizable — nunca se aproxima con otra fuente.

Iniciativas legislativas

Los parlamentarios presentan mociones (el Presidente presenta mensajes). PoliScore muestra «mociones presentadas» y, por separado, «mociones convertidas posteriormente en ley» — nunca «leyes presentadas». La coautoría no se cuenta como autoría exclusiva.

Discrepancias con SERVEL

Si el cálculo D'Hondt de PoliScore no reproduce exactamente la asignación oficial de un territorio, esa importación se detiene y el caso se documenta. PoliScore no adapta el algoritmo para forzar la coincidencia.

Modelo del puntaje

El puntaje compuesto es una suma ponderada de cinco sub-escalas, cada una en 0–100:

score_total = 0.40 · poll_score
            + 0.15 · poll_trend_score
            + 0.25 · news_score
            + 0.10 · management_score
            + 0.10 · controversy_score        (acotado a 0–100)
Sub-escalaPesoCómo se calcula
poll_score40%Media ponderada (recencia × muestra × credibilidad de la casa†) de las encuestas de los últimos 45 días, cada una normalizada a 0–100.
poll_trend_score15%Pendiente reciente de esas encuestas: media de la ventana corta (28 d) menos la anterior, combinada con una ventana más corta. 50 = plano.
news_score25%50 + aporte neto de eventos de tipo news/event, con decay exponencial (vida media 6 d).
management_score10%50 + aporte neto de eventos de gestión (decay más lento, vida media 20 d).
controversy_score10%50 + aporte neto de controversias (normalmente negativo; vida media 8 d).

Como cada sub-escala ya está en 0–100, la suma ponderada cae en 0–100 por construcción; igualmente se aplica un clamp final.

Normalización de encuestas

No se suman porcentajes de escalas distintas. Cada medición se transforma primero a una escala común 0–100 (100 = mejor):

Escala de origenTransformación
approval_pct (0–100)directo
net_favorability (−100…100)(v + 100) / 2
scale_1_7 / scale_1_10reescalado lineal a 0–100

Cada encuesta pesa según su recencia (decay, vida media 18 d), su tamaño de muestra (∝ √n, con tope) y la credibilidad de la casa. Si no hay encuestas en la ventana, poll_score = 50 y la confianza cae.

† Credibilidad de la casa: hoy es neutral e idéntica para todas las encuestadoras (factor 1.0, sin excepción). Auditamos si existía evidencia objetiva (error frente a un resultado electoral real, sesgo sistemático histórico, tamaño de muestra, antigüedad, transparencia metodológica declarada) para calcular un peso distinto por casa, y hoy no la hay: la medición más antigua registrada es de mayo de 2026, no existe ninguna elección posterior comparable, y ninguna casa tiene series lo bastante largas para estimar un sesgo con significancia estadística. Mientras no exista esa evidencia, PoliScore no le asigna a mano un número de "confiabilidad" a ninguna encuestadora — sería una opinión, no un dato. El campo queda preparado en el código para calibrarse automáticamente el día que haya evidencia suficiente. Ver registro de cambios metodológicos.

De la noticia al puntaje

Una regla central: 20 publicaciones de la misma noticia no son 20 eventos. La cadena es:

Noticia→Evento→Político→Impacto→Magnitud→Confianza→Decay temporal
  1. Noticia: cada publicación individual de un medio.
  2. Evento: las noticias que cubren el mismo hecho se agrupan por cluster_key en un único evento. El número de fuentes se guarda como señal de relevancia, no como multiplicador de eventos.
  3. Político → Impacto: el evento se asocia a uno o más políticos con un impacto firmado (positivo o negativo) en puntos de puntaje.
  4. Magnitud: tamaño base del hecho (0–1), independiente de a quién afecta.
  5. Confianza: qué tan sólido es el impacto, según cantidad y credibilidad de las fuentes (0–1).
  6. Decay temporal: el impacto decae de forma exponencial. Vida media ≈ 6 días para noticias/eventos: a los ~6 días un evento pesa la mitad; a las dos semanas, cerca de un cuarto. Gestión decae en ~20 días y controversias en ~8.

El aporte vigente de un evento es exactamente:

effective_impact = impact · confidence · decay_factor(edad)

decay_factor(edad) = 0.5 ^ (edad_en_días / vida_media)

source_count (número de notas agrupadas) no multiplica el impacto: 20 notas del mismo hecho aportan lo mismo que una. Solo influye en la confianza.

Clases de señal

Cada evento se clasifica en una de cinco clases de señal. El modelo mantiene esta distinción internamente para la próxima fase (ingesta real), aunque el algoritmo de ponderación todavía no cambia:

Encuesta Cobertura / noticia Evento Gestión / hecho verificable Controversia

Cada movimiento almacena, además: impact (aporte firmado en t0), confidence (0–1), source_count (noticias agrupadas), occurred_at y el decay vigente. Es el contrato que consumirá el pipeline real.

Explicación de cada variación

La explicación sale directamente de los números del cálculo, no de un relato aparte. La variación entre dos fechas se descompone en los cinco componentes ponderados:

Δ = 0.40·Δpoll_score + 0.15·Δpoll_trend_score
  + 0.25·Δnews_score + 0.10·Δmanagement_score
  + 0.10·Δcontroversy_score

La suma de los cinco deltas es igual a la variación del puntaje.

Ejemplo real (variación 30 días de una figura del índice):

Variación 30D: +6.2

+3.7  Encuestas
+2.2  Tendencia
+0.3  Eventos / noticias
+0.1  Gestión
-0.1  Controversias
----------------------
Suma  +6.2

Principal explicación:
El avance se explica principalmente por encuestas y tendencia.

La frase solo nombra componentes cuyo delta supera un umbral: no se generan explicaciones que los números no respalden.

Puntaje de confianza

Cada político tiene una Confianza 0–100 que no mide si lo hace bien, sino cuántos datos recientes y confiables hay para calcular su puntaje. Combina seis factores:

Un político con pocos datos igual tiene puntaje, pero con confianza baja: sin encuestas recientes la confianza queda con techo de 35.

Trazabilidad y snapshots

Cada día se guarda un snapshot inmutable por político con: score_total, las cinco sub-escalas, confidence_score, la etiqueta de tendencia, y calculated_at / engine_version. Los snapshots pasados no se sobrescriben: recalcular el presente solo agrega días nuevos. Como el motor es determinista y "a fecha" (as-of), cualquier puntaje histórico se puede reconstruir.

Inteligencia: Impulso, Volatilidad y Consenso de Encuestas

Tres métricas derivadas, deterministas y reproducibles: se calculan solo desde la serie de snapshots y las encuestas. No hay explicación fuera de los números; cada una expone sus componentes (/api/v1/intelligence).

Impulso (momentum, −100 … +100)

Combina el movimiento reciente, el de mediano plazo y la aceleración, y lo pondera por la eficiencia de la trayectoria para distinguir un crecimiento sostenido de un salto puntual.

r7    = score(t) − score(t−7)                       [pts/semana]
r30w  = (score(t) − score(t−30)) · 7/30             [pts/semana equiv.]
accel = r7 − ( score(t−7) − score(t−14) )           [cambio de la tasa semanal]

blend      = 0.45·r7 + 0.35·r30w + 0.20·accel
efficiency = |score(t) − score(t−30)| / Σ|Δ diario en 30d|      (0…1)
sustain    = 0.5 + 0.5·efficiency

momentum = 100 · tanh( blend · sustain / 4.0 )

Una trayectoria limpia (efficiency ≈ 1) mantiene todo el peso; un movimiento que sube y baja (efficiency baja) se amortigua hasta la mitad. Etiqueta: «sostenido» si efficiency ≥ 0.55, si no «salto puntual».

Volatilidad (volatility, 0 … 100)

Cuánto oscila el PoliScore día a día en 30 / 60 / 90 días (desviación de los cambios diarios; un ascenso suave no cuenta como volátil).

σ_W    = desviación estándar (poblacional) de los Δ diarios del score en W días
vol_raw = (0.5·σ_30 + 0.3·σ_60 + 0.2·σ_90) / (Σ pesos con datos)

volatility = 100 · ( 1 − exp( −vol_raw / 0.9 ) )

Consenso de Encuestas (poll_consensus, 0 … 100)

Grado de acuerdo entre encuestadoras. Alta dispersión = menor consenso. Sobre las encuestas de los últimos 45 días, normalizadas a 0–100, con peso de recencia 0.5^(edad/21):

sd = desviación estándar ponderada de los valores normalizados

poll_consensus = 100 · exp( −sd / 4.5 )

Requiere ≥ 2 encuestadoras distintas en la ventana; si no, queda «no disponible» y no entra al ranking.

Laboratorio de Datos y exportaciones

El Laboratorio de Datos consulta las series por político / período / métrica. Cada exportación (CSV, XLSX, JSON, PYTHON) incluye generated_at, data_mode, engine_version, período y campos utilizados.

Endpoints equivalentes: /api/v1/data, /api/v1/intelligence, /api/v1/data/export?fmt=csv|xlsx|json|py.

Estado de esta versión

El motor de puntuación está implementado y probado (suite en tests/). El sitio público (REAL BETA) lo alimenta con datos reales verificados; la base simulada (app/seed.py → poliscore.db) queda solo para las pruebas. Los endpoints /api/v1/ranking, /api/v1/politician/{slug}, /api/v1/real, /api/v1/intelligence, /api/v1/news y /api/v1/events exponen los datos reales en JSON.