The context layer your agents run on.
iDash creates a clear business model from your connected data. Your team refines it, and every answer is calculated consistently based on those shared definitions.
Semantic model
4 models · 3 relationships · derived from foreign keys
- PKcustomer_iduuid
- FKregion_idint
- first_order_attimestamptz
- channeltext
- PKorder_iduuid
- FKcustomer_iduuid
- placed_attimestamptz
- net_revenuenumeric
- PKproduct_idint
- categorytext
- unit_costnumeric
- PKitem_iduuid
- FKorder_iduuid
- FKproduct_idint
- quantityint
- customers1:Norders
- orders1:Norder_items
- products1:Norder_items
What sits between question and warehouse.
A schema tells you which columns exist. A model tells an agent what they mean, how they connect, and how they may be counted.
Clear business definitions
Your data is mapped with clear business labels and relationships. Answers are always based on verified definitions rather than guesses.
Reliable data connections
Connections between records are mapped automatically. Questions resolve across verified relationships so related data is combined accurately.
Metrics defined once
Revenue carries its filters and its grain in the model. Every question that mentions it resolves to the same calculation, whoever asked and from whichever surface.
Structured queries
Questions are converted into precise, structured requests with defined calculations and filters, eliminating subtle query errors.
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.
Verified calculations
Instead of asking AI to guess calculations on the fly, iDash uses verified metrics and relationships defined for your business.
Consistent results
The same question always yields the same accurate calculation every time. Different phrasing in chat still produces consistent, reliable answers.
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.
Question
What was revenue by region last quarter?
Resolved
- model
- orders
- measure
- sum(orders.net_revenue)
- dimension
- regions.region_name
- grain
- order_id
Join path
- customers.customer_id · many to one
- regions.region_id · many to one
Primary key dedup applied on order_id
order_items multiplies each order row 3.4 times on average. Revenue is measured on the order grain, so the compiler dedups on the primary key before aggregating.
Compiled plan
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- Join path resolved, 2 hops, no ambiguity
- Primary key dedup applied on orders.order_id
- One inflated model in the query, single dedup CTE is sufficient
- Read only connection, statement timeout 30s
- 5 rows · 412ms
Built by introspection, refined by your team.
Nobody starts a modelling project from nothing. iDash writes the first version from your warehouse, and the people who know the business correct it.
Introspection writes the draft
Connecting reads tables, columns, primary keys and foreign keys, and turns them into a model you can query the same afternoon.
Curation makes it yours
Rename fields into the words your team uses, hide what nobody should read, and write down the definitions people currently argue about in meetings.
It tracks the warehouse
Schemas move. Reconnecting picks up new tables and columns and shows what changed, so the layer your agents run on stays the layer you approved.
See what your schema already knows.
Connect a read-only replica and read the model iDash builds from it before you ask a single question.