Qué es DataAtlas

DataAtlas responde dónde están los datos de un cliente, con evidencia: en qué motor y base física viven, en qué tablas, con cuántas filas, de qué fechas, desde qué fuentes y qué tan frescos. No responde preguntas analíticas (totales, márgenes, comparaciones): para eso te da el SELECT base listo para el warehouse.

Para el analista

Búsqueda en lenguaje natural

En español, portugués o inglés:

• «¿de dónde saco las ventas?» · «onde estão as vendas?» · «where are the weighings?»
• «¿cuáles son todas las tablas con datos de este cliente?» — pedir el inventario también funciona: responde el mapa de cobertura completo.

Cada resultado muestra por qué matcheó (tabla y columnas), la cobertura real del cliente, y arriba de todo dónde vive físicamente su warehouse (motor, base, conexión) — cada cliente puede tener el canónico en Postgres, Snowflake o DuckDB. Los números salen del Tenant Data Map (computado y verificado determinísticamente), nunca de la IA.

Cuando no hay datos — y por qué

DataAtlas nunca inventa un resultado para aparentar que responde. Si no hay, distingue la causa: «no está en el canónico» (el concepto no existe en el modelo) o «el canónico lo modela pero este cliente no lo pobló» (activá «incluir vacías» para ver ese potencial). Y si un término de tu pregunta es un valor de los datos y no una tabla o columna (p. ej. «soja»), te lo dice: los resultados corresponden al resto de la consulta y ese valor se filtra en el SQL.

Preview y SELECT

El preview muestra hasta 50 filas del cliente seleccionado, con columnas sensibles enmascaradas (•••), y queda auditado. «Copiar SELECT» te da la consulta base en el dialecto del warehouse de ese cliente, ya filtrada por tenant.

Feedback

👍 si sirvió, 👎 si es incorrecto, «No encontré lo que buscaba» si sabés que el dato existe: esa señal ajusta el ranking (job diario) y alimenta el backlog de sinónimos y fuentes por integrar.

Frescura

fresh llegó dentro de 2× su cadencia habitual · stale demorado (2–6×) · dormant sin cargas hace mucho. Las transiciones generan alertas automáticas (ver Notificaciones).

¿Cuándo aparecen los datos nuevos?

Solos, sin intervención humana. Cuando un archivo del cliente cae en RAW y DataRefinery lo procesa, Atlas se entera por su cuenta:

• Cobertura (~1 minuto): un poller mira los runs procesados de DataRefinery cada minuto; el dashboard, la frescura y los conteos se actualizan solos.
• Búsqueda (~5 minutos): los índices de búsqueda se refrescan por su propio TTL; el dato nuevo pasa a ser encontrable a los pocos minutos de aterrizar.
• Tablas recién estrenadas (~1 minuto): si llega una carga de una tabla que el espejo local del catálogo todavía no conoce (DataRefinery la acaba de publicar), Atlas dispara un sync de catálogo inmediato en vez de esperar el ciclo horario.
• Verificado cada noche: la reconciliación recuenta todo de verdad en el warehouse y corrige cualquier estimación que haya derivado.

Los únicos puntos con humano en el circuito son los que lo merecen: filas en cuarentena (rechazadas por el contrato de datos, visibles por tabla) y los hallazgos de gobernanza en Salud.

Para el administrador

Cada pantalla tiene sus propios tooltips «?» con el detalle; esto es el mapa.

• Admin — Settings: TODA la configuración operativa vive en la DB de metadata, releída en caliente (sin reiniciar) y documentada en el lugar (qué es cada clave, contra qué conecta y qué permisos requiere la credencial guardada), con los secretos enmascarados para siempre una vez guardados. Entra en el backup diario de la metadata, así que un restore trae toda la configuración de vuelta solo; en el .env queda únicamente el bootstrap (la dirección de esta DB, admin token, secret key) y la topología de proceso. Las credenciales de conexión a DataRefinery (DSN de interop, API de catálogo) se validan antes de guardarse y se aplican en caliente. Además, API keys (por cliente, multi-tenant, de servicio o admin; revocar y borrar revocadas; el token se muestra una sola vez), Composer (LLM) (proveedor DeepSeek/OpenAI/Gemini/Azure/ Anthropic, modelo y key, con botón de prueba), fondo del login (subí una imagen: se valida, re-encodea y redimensiona sola) y el registro de Notificaciones emitidas.
• Preguntas — el log completo de lo que se preguntó y respondió: quién, cuándo, latencia, con filtros y búsqueda en pregunta y respuesta. El filtro «sin resultado» es el backlog de qué integrar.
• Probar API — disparás una pregunta contra la API HTTP real (con auth, rate limit y todo) y ves el JSON crudo, la latencia y el curl equivalente para pasarle a un integrador.
• Stats — uso del sistema, recursos de la máquina (24 h) (CPU, memoria, disco, IOPS, usuarios activos: los picos dimensionan el hardware) y consumo por credencial (search/ask/preview: la base de facturación).
• Conexiones — las cuentas de warehouse (Postgres, Snowflake con key-pair, ClickHouse, Databricks, DuckDB) con test y activación, y la asignación por tenant: qué cliente vive en qué motor.
• Auditoría — registro append-only de toda acción administrativa (incluidos los intentos rechazados), con cadena de hashes: alterar o borrar una entrada rompe la cadena y se delata solo.
• Salud — 9 chequeos (metadata, interop, catálogo, warehouse, watermark, reconciliación, composer, secrets, integridad de la auditoría), los hallazgos de gobernanza abiertos (drift, datos desaparecidos, cargas fuera del pipeline, contracts aprobados sin datos — se cierran solos cuando dejan de reproducirse) y las acciones de reparación idempotentes.

Alertas hacia afuera

Un solo caño de salida: transiciones de frescura, hallazgos de gobernanza y el digest semanal de gaps. Configurá notify.webhook_url (y notify.webhook_token opcional) en los settings de Admin; sin webhook, todo queda registrado localmente igual.

Para integradores y agentes de IA

El contrato vivo está en /openapi.json (todas las operaciones tipadas, con rol requerido por operación): pinealo y vigilalo. Auth por header X-API-Key con una key creada en Admin — scoped a un cliente (terceros) o multi-tenant (sistemas propios). Rate limit por credencial (editable online). GET /whoami le dice a cualquier credencial su propio alcance.

• POST /search — hechos estructurados: candidatos con evidencia, not_found_reason (para decidir el fallback sin adivinar), warehouse (motor/base/conexión del tenant) y sample_query en su dialecto.
• GET /coverage/tenants/{id} — qué tiene poblado el cliente, por dominio.
• GET /tables/{fqn} — ficha completa: columnas, significados, linaje.
• GET /tables/{fqn}/related — con qué tablas se une y por qué columna (con shared_by para distinguir clave hub de vínculo específico): el eslabón para encadenar SQL sin saltos ciegos.
• GET /tables/{fqn}/preview — muestra gobernada (límite duro, sensibles enmascaradas, auditada).
• POST /feedback — cerrar el loop (useful/wrong/missing).

Para un agente conviene /search y no /ask: el agente ya tiene su LLM — necesita hechos, no redacción.