Estado al 22 de octubre de 2026 · 12 tablas en PostgreSQL, que es la única fuente de verdad del producto
| Tabla | Qué guarda y por qué existe |
|---|---|
| eventos | El hecho: fecha, territorio, comuna, canal que lo reportó, fuente, cita verificable, el asunto completo y cómo lo titula la propia fuente. Sin fuente, fecha y cita no entra. Lleva también el puntero al documento original (url, id de expediente, archivo del corpus) como campos, no escondido dentro del texto. |
| eventos_categorias | Qué riesgo representa cada hecho. Tabla aparte porque un evento puede ser varias cosas: un escape que terminó en protesta es escape y conflicto, y contarlo en una sola subestima el riesgo que no se contó. Guarda quién la puso (reglas, modelo o humano) y con qué confianza. |
| eventos_etiquetas | Vocabulario abierto que la fuente YA daba y se estaba botando: empresa, centro con su RNA, expediente, tema del medio. El valor va normalizado para agrupar ("AQUACHILE S.A." y "AquaChile SpA" son la misma empresa) y también tal como se muestra. |
| territorios | Las zonas que el cliente monitorea, con sus coordenadas. Vienen de su planilla, no son un hardcode. |
| Tabla | Qué guarda y por qué existe |
|---|---|
| clasificaciones_modelo | Lo que concluyó el comité de dos modelos para cada TEXTO distinto, no para cada evento: 2.288 eventos salen de 487 textos, así que preguntar por evento sería pagar cinco veces lo mismo. Guarda también lo que dijo el segundo modelo cuando no hubo acuerdo. La clave incluye una huella del prompt, para que cambiar la taxonomía invalide la caché sola y el corpus no quede mezclando dos criterios. |
| correcciones_clasificacion | Lo que una persona corrigió, con su motivo. Se re-aplica antes de clasificar en cada corrida, así que una corrección sobrevive: sin esto, cada corrida reconstruye los eventos desde cero y la corrección se perdía al día siguiente. El motivo es lo que después enseña al clasificador. |
| observaciones_evento | Lo que el usuario marca desde la ficha, por dos caminos: "esto está mal" (corrige categorías) y "acá falta algo" (texto libre). El segundo existe por una razón medida: un cliente corrige lo que ve y nunca lo que falta, así que con un solo camino el sistema mejoraría la precisión, que ya está en 97%, y jamás el recall, que es el flojo. |
| Tabla | Qué guarda y por qué existe |
|---|---|
| documentos_evento | El texto ya tachado de cada resolución leída, nunca el crudo: las resoluciones traen nombre y domicilio de quien denunció. Guarda cómo se extrajo (capa de texto u OCR), qué páginas se omitieron por datos de personas, el hash del archivo original y dónde quedó guardado ese archivo. Existe por costo y por evidencia: leer un expediente son dos minutos de reconocimiento, y sin esto cada persona que abra el mismo evento los paga de nuevo. |
| Tabla | Qué guarda y por qué existe |
|---|---|
| corridas | Una fila por pasada del pipeline, con sus conteos. Permite medir tendencia y saber cuántos días lleva un canal sin aportar. |
| corrida_artefactos | Los resultados de la corrida: scores, matriz de riesgos, salud de fuentes, termómetro, alertas, replay y los pesos usados. Van como documento por corrida y no en tablas relacionales porque el front los consume enteros y se regeneran completos cada día. Entran en la misma transacción que los eventos: una corrida con eventos pero sin su matriz de riesgos es una corrida a medias. |
| subsanaciones | La gestión registrada sobre una alerta. Vivía en un archivo y en el navegador de cada persona; ahora es compartida, que es lo que un equipo necesita. |
| migraciones | Qué cambios de esquema se aplicaron. Cada uno corre una sola vez y dentro de una transacción. |
Dos reglas que viven en el SQL y no en el código, para que se cumplan venga de donde venga la escritura: a lo que corrigió un humano el pipeline no le cambia categorías ni le agrega otras (agregar también es pisar, porque la corrección declara el conjunto completo); y un evento es el mismo hecho aunque lo reporten dos fuentes, así que la clave natural lo deduplica.