Cómo responde una pregunta

Cada pregunta a David recorre el mismo camino de cinco etapas. En cada una hay un punto de control que puede detener el proceso: David prefiere no responder antes que responder una cifra que no puede respaldar.

pregunta ─► 1 intención ─► 2 reglas ─► 3 compilación + guardrail ─► 4 ejecución ─► 5 respuesta + auditoría
               │              │                  │                        │
         ¿ambigua?      ¿hay un dominio     ¿pasa el árbol          ¿hay conexión
         → aclarar      con permiso?        sintáctico?             configurada?
                        → bloquear          → bloquear              → entregar la consulta certificada

#1. Intención

La pregunta en lenguaje natural se traduce a una solicitud estructurada: métricas, dimensiones, filtros y rango de fechas, solo con nombres que existen en la capa semántica.

• Con un modelo de lenguaje disponible, Claude recibe solo el índice liviano de la capa semántica (nombres y descripciones, sin SQL ni columnas) y devuelve la solicitud.
• Sin modelo, un emparejador determinista usa los sinónimos del glosario y las anclas.
• Si la pregunta es ambigua (por ejemplo, “ventas” puede ser GMV bruto o GMV neto entregado), David pide una aclaración con las opciones posibles, en vez de suponer.

{
  "metrics": ["gmv", "payments_total"],
  "dimensions": ["customer_state"],
  "dateRange": { "from": "2018-01-01", "to": "2019-01-01" }
}

#2. Reglas y dominio

David trae solo las definiciones y las reglas de negocio de lo que se pidió (recuperación en dos etapas: primero el índice, después el detalle). Luego elige el dominio que responde: un subagente con permiso de mínimo privilegio sobre un conjunto de tablas (por ejemplo, Finanzas, Comercial u Operaciones). Si ningún dominio tiene permiso sobre todas las tablas que exige la pregunta, se bloquea.

#3. Compilación y guardrail

El SQL lo escribe un compilador determinista, nunca el modelo:

• Recorre solo joins certificados de muchos a uno desde la tabla de hechos de cada métrica.
• Si las métricas vienen de tablas de hechos distintas (ventas y pagos), agrega cada una por separado en su propio bloque y une los resultados al final.
• Si una vista pedida cruzaría una relación de uno a muchos que duplicaría filas (por ejemplo, GMV por medio de pago), la rechaza y explica por qué.
• Usa siempre valores parametrizados, filtro de cliente cuando la tabla lo exige y un límite de filas.

Después, el guardrail analiza el SQL compilado como árbol sintáctico. Ver Consultas seguras.

#4. Ejecución

La consulta certificada se ejecuta en tu base de datos a través de una herramienta de tu servidor MCP (por ejemplo, run_query), con un usuario de solo lectura. El cálculo lo hace tu motor de base de datos.

#5. Respuesta y sello de auditoría

La respuesta se redacta con los números exactos del resultado. Si se usa un modelo para resumir, el resumen se descarta automáticamente si contiene una cifra que no está en las filas devueltas, y queda la redacción determinista.

{
  "ok": true,
  "status": "ANSWERED",
  "answer": "En 2018, el estado con mayor GMV fue … (cifras tomadas tal cual de las filas)",
  "rows": [ { "customer_state": "…", "gmv": "…", "payments_total": "…" } ],
  "sql": "WITH m1 AS ( … ), m2 AS ( … ) SELECT … LIMIT 1000",
  "audit": {
    "at": "2026-11-02T15:10:04.000Z",
    "queryHash": "9b1c…",
    "specVersion": "2026-10-26",
    "lineage": ["olist_order_items", "olist_orders", "olist_customers", "olist_order_payments"],
    "domain": "finance",
    "assumptions": []
  }
}

#Estados posibles

#Errores de compilación