Especificación · SIG

Modelo de datos

El SIG guarda todo bajo un único nodo raíz con cuatro hijos. La estructura es deliberadamente plana: dos niveles para los documentos y ninguna relación implícita que haya que reconstruir en el cliente.

Vista general

sig/
├── archivos/{slug}/{clave}      ← el catálogo documental
├── carpetas/{slug}/{id}         ← carpetas creadas a mano por un administrador
├── descargas/{correo}/{id}      ← registro de descargas con sesión iniciada
└── chatbot/conversaciones/{id}  ← hilos del asesor virtual
     ├── meta                    ← estado, idioma, página, usuario, fechas
     └── mensajes/{id}           ← cada turno de la conversación

Los binarios no viven en la base de datos: se almacenan aparte, en un bucket de archivos, y el registro guarda la ruta y la dirección de descarga. Esa separación es lo que permite que el listado de un proceso se cargue al instante aunque el proceso tenga cientos de megabytes publicados.

archivos · el catálogo documental

sig/archivos/{slug}/{clave}

Un registro por documento publicado. El primer nivel es el slug del proceso (gth, pet…) y el segundo una clave generada al publicar, que es la que aparece en el enlace de descarga.

nombre
Nombre completo del archivo, con su código al principio. Es el nombre público del documento y la fuente del tipo documental.
carpeta
Carpeta a la que pertenece dentro del proceso. Es lo que agrupa las píldoras del listado. Un solo nivel: no hay subcarpetas.
formato
Etiqueta legible derivada de la extensión: «Word», «Excel», «PDF». Es lo que se muestra en la tarjeta.
peso
Tamaño en bytes, tomado de los metadatos del archivo almacenado.
fechaSubida
Marca de tiempo de la publicación, en milisegundos.
storagePath
Ruta dentro del almacenamiento: /sig/archivos/{slug}/{carpeta}/{nombre}. Refleja la misma jerarquía que la base de datos.
url
Dirección de descarga directa del binario, con su testigo de acceso.
metadata
Metadatos del objeto almacenado: bucket, ruta completa, hash y fechas de creación y actualización.
uploader
Dato personal. Identificador, correo y nombre de quien publicó el archivo. Se conserva para trazabilidad interna y nunca se expone en la API pública ni en esta documentación.
La clave no es el código. El código (FR-IFO-01.02) vive dentro del campo nombre; la clave del registro es un identificador opaco. Al publicar una versión nueva se crea un registro con clave nueva, y por eso el enlace de la versión anterior deja de resolver. Ver Enlaces de descarga.

carpetas · las creadas a mano

sig/carpetas/{slug}/{id}

Registro de las carpetas que un administrador creó explícitamente escribiendo su nombre. Sirve para que aparezcan en el selector de carga aunque todavía no tengan documentos.

nombre
Nombre de la carpeta, tal como se escribió.
createdAt
Cuándo se creó.
createdBy
Dato personal. Correo de quien la creó. No se publica.
Las píldoras no salen de aquí. Las carpetas que ve el usuario se derivan del campo carpeta de los documentos publicados. Una carpeta registrada pero vacía no aparece como píldora; y una carpeta que existe solo porque alguien escribió su nombre al subir un archivo aparece igualmente aunque no esté en este nodo.

descargas · el uso real

sig/descargas/{correo saneado}/{id}

Un registro por descarga realizada con sesión iniciada. El primer nivel es el correo del usuario con los puntos sustituidos, porque las claves de la base de datos no admiten puntos.

fechaDescarga
Cuándo se descargó.
archivoKey
Clave del documento descargado.
slug
Proceso al que pertenece, o nulo en los enlaces antiguos sin proceso.
nombre formato peso
Copia de los datos del archivo en el momento de la descarga, para que el registro siga siendo legible aunque el documento se retire después.
La clave del primer nivel es un dato personal. Por eso las cifras que publica esta documentación se calculan agregando —cuántas descargas, cuántas personas distintas, cuántas por proceso— sin exponer nunca el correo ni el detalle individual.

chatbot · las conversaciones

sig/chatbot/conversaciones/{id}/meta

Estado y contexto del hilo.

status
activa o cerrada.
lang
Idioma detectado de la conversación.
page
Página desde la que se abrió el chat. Permite saber si se pregunta desde la portada o desde la ficha de un proceso.
createdAt lastActivity
Cuándo empezó y cuándo tuvo actividad por última vez.
needsAdmin needsAdminSince adminAssigned
Marcan que se pidió atención humana, desde cuándo y quién la tomó.
closedAt closedBy
Cuándo se cerró y quién la cerró.
userId userEmail userName userPhoto
Datos personales. Identifican a quien conversó. No se publican.

sig/chatbot/conversaciones/{id}/mensajes/{id}

Cada turno de la conversación, en orden cronológico.

role
user o assistant.
timestamp
Momento del mensaje.
content
Contenido de la conversación. Puede incluir información que la persona escribió sobre su situación. No se publica ni se analiza en esta documentación.

Qué se publica y qué no

Esta documentación lee producción para mostrar cifras vivas. La proyección que hace es deliberadamente estrecha.

Se publicaNo se publica nunca
Conteos de documentos por proceso, tipo, carpeta y formato Correo, nombre o identificador de quien subió un archivo
Volumen total del repositorio y fecha de la última publicación Direcciones de descarga directa del almacenamiento
Número de descargas y número de personas distintas Qué descargó cada persona
Conteos de conversaciones, mensajes, estados e idiomas El contenido de las conversaciones
Páginas desde las que se abre el chat Correo, nombre o foto de quien conversó
Estructura institucional: procesos, líderes y correos de dependencia Cualquier dato que identifique a una persona natural
Los correos de los líderes sí se publican porque son buzones institucionales de dependencia (talentohumano@, juridica@…), no direcciones personales. Están además publicados en el propio sitio del SIG.

Dos detalles del modelo que conviene conocer

Enlaces con y sin proceso

Existen documentos registrados directamente bajo sig/archivos/{clave}, sin nivel de proceso. Son anteriores a la organización actual; la página de descarga los sigue resolviendo.

Correos como claves

El nodo de descargas usa el correo con los puntos sustituidos como clave, igual que el registro de usuarios de la suite. Es el puente entre ambos.

Por dónde seguir

API pública

Qué proyección de este modelo se expone hacia fuera.

Infraestructura

Dónde vive cada pieza y cómo se sirve.

El repositorio

El estado real de estos nodos hoy.

Autenticación

Quién puede escribir en cada nodo.