El catálogo de datos que no se pudre

Todo el que ha trabajado con datos empresariales conoce el ciclo: alguien arma un diccionario de datos en Excel o en un wiki, se celebra, y seis meses después nadie lo ha actualizado. La columna nueva no está, la tabla renombrada sigue con el nombre viejo, y los analistas vuelven a lo de siempre — adivinar qué significa cada columna por el nombre. Con la IA el problema se multiplica: un agente que adivina mal no duda, ejecuta.

Lo que construimos en cambio

Para nuestro despliegue en producción construimos tres piezas, todas dentro de la base de datos, no al lado de ella:

• El diccionario oficial — una tabla curada de descripciones unida en vivo al inventario real de Postgres (pg_catalog). Si una columna existe, aparece; si no está documentada, el sistema lo dice honestamente (documented = false) en vez de inventar. Hoy: ~4,500 entradas curadas sobre 600+ tablas y vistas.
• La capa semántica de joins — cómo se unen las tablas, con las columnas exactas, la cardinalidad y las trampas. Incluye relaciones NON-JOIN: pares de columnas que parecen unibles y NO lo son, documentadas para que nadie (humano o agente) caiga dos veces.
• El mapa interactivo — un HTML autocontenido generado desde la base: busca una tabla, ve su descripción, su llave primaria y cada relación con un clic. Regenerarlo es un comando.

La parte que casi nadie hace: verificar contra la fuente

Describir una columna por su nombre es fácil y peligroso. Nuestro estándar es otro: extrajimos el SQL original del ERP del cliente (más de 1,500 consultas de sus formularios y reportes) y reconciliamos tres vías: lo que dice el ERP, lo que hay en el espejo de datos, y lo que calculan nuestras vistas — hasta el centavo. Las descripciones que pasaron por esa auditoría llevan un sello (verificado ✓) distinto de las descripciones razonables-pero-no-auditadas.

Ese proceso encontró joyas que ningún diccionario por nombre habría capturado:

• Una columna llamada cantidad_regalia que no registra regalías — es un contador de despacho.
• Un tipo de documento que guarda el costo por unidad cuando todos los demás lo guardan por empaque — un error de agregación de 77× esperando a quien no lo supiera.
• Números de factura que se repiten entre tipos de documento: todo join que no incluya el tipo está silenciosamente mal.

Agents-first: el catálogo como herramienta de la IA

Aquí está el giro que lo cambia todo: el primer consumidor del catálogo no es una persona — son los agentes de IA. Antes de escribir SQL, nuestros agentes consultan el diccionario (¿qué significa esta columna?) y la capa de joins (¿cómo se une esto, y por dónde NO?):

$ apexia-pg-joins tfat_factura tinv_producto
  2 saltos: factura → kardex (tipo_factura,no_factura) → producto
  ⚠ la clave INCLUYE tipo_factura — no_factura se repite entre FT/AN/FC

Y cuando un agente descubre un join que no estaba documentado, lo verifica contra la fuente y lo inserta de vuelta en la capa. El catálogo se enriquece con el uso. Por eso no se pudre: no depende de la buena voluntad de nadie — es el camino de menor resistencia para hacer el trabajo.

Esto también es un servicio

Lo que describimos arriba es exactamente lo que las plataformas de catálogo empresarial venden por decenas de miles de dólares al año — con una diferencia: lo nuestro corre dentro de tu Postgres, se regenera solo, se verifica contra tu ERP real, y no le paga renta a nadie. Si tu empresa tiene un ERP con años de historia y nadie sabe ya qué significa la mitad de las columnas, ese es precisamente el problema que sabemos resolver.