The context layer your agents run on.

Why you can trust it

Why an agent here can be trusted.

A text to SQL agent is trusted to remember your warehouse correctly. An agent on a semantic layer is not trusted with that at all.

WITH orders_dedup AS (
  SELECT DISTINCT ON (o.order_id)
         o.order_id, o.customer_id, o.net_revenue, o.placed_at
    FROM orders o
    JOIN order_items oi ON oi.order_id = o.order_id
)
SELECT r.region_name,
       SUM(od.net_revenue) AS net_revenue
  FROM orders_dedup od
  JOIN customers c ON c.customer_id = od.customer_id
  JOIN regions   r ON r.region_id   = c.region_id
 WHERE od.placed_at >= DATE '2026-05-01'
   AND od.placed_at <  DATE '2026-08-01'
 GROUP BY r.region_name
 ORDER BY net_revenue DESC

• Selection, not generation

  Text to SQL asks a language model to recall your schema and produce a string. Here it chooses from a model that already carries the keys.

• Deterministic resolution

  The same query against the same model compiles to the same SQL every time. Phrasing changes the conversation, not the plan underneath it.

• One layer, every surface

  Chat, dashboards, embedded views and anything built on the API resolve through the same models and metrics. Two surfaces cannot quietly disagree about revenue.

• It says what it cannot

  Where the model cannot express a question, iDash names the missing piece rather than inventing a column. You get a modelling task back, not a plausible number.

WITH orders_dedup AS (
  SELECT DISTINCT ON (o.order_id)
         o.order_id, o.customer_id, o.net_revenue, o.placed_at
    FROM orders o
    JOIN order_items oi ON oi.order_id = o.order_id
)
SELECT r.region_name,
       SUM(od.net_revenue) AS net_revenue
  FROM orders_dedup od
  JOIN customers c ON c.customer_id = od.customer_id
  JOIN regions   r ON r.region_id   = c.region_id
 WHERE od.placed_at >= DATE '2026-05-01'
   AND od.placed_at <  DATE '2026-08-01'
 GROUP BY r.region_name
 ORDER BY net_revenue DESC