The question is the interface.
iDash is built by Gateway Group, a global software engineering house that got tired of the request queue.
Learn SQL, or wait for someone.
Every generation of business intelligence has offered the same two options. iDash removes both by making the question the interface and the compiler the guarantee.
For thirty years the deal has been the same. Either you learn the query language, the joins and the grain of every table, or you write a request and wait for a person who already did. Self-service dashboards were supposed to end that, and mostly they moved the queue: now you wait for a chart to be built instead of a query to be run.
Meanwhile the questions did not get simpler. They got more urgent and more specific, and they arrive in the language people actually speak. Which region slipped last month. Whether refunds moved after the pricing change. How many accounts have gone quiet since March.
Language models made those questions answerable, and immediately introduced a worse problem. A model that writes SQL will happily write a join that inflates a total, hand you a number that looks reasonable, and never mention it. Confident and wrong is a downgrade on slow and right.
So we split the problem. The model handles language, which is what it is good at: understanding what you meant and choosing metrics and dimensions from a model your team curated. The compiler handles correctness, which the model should never have been trusted with: resolving the join path, working out where a join would double count, deduplicating on primary keys, and refusing when it cannot prove the shape.
That is the whole thesis. Ask in your own words. Get an answer that a compiler is willing to defend, or get told why not.
How we build
Five rules we build against.
These are the rules work gets checked against, not values on a wall. Each one has said no to a feature at least once.
01
Trust the number before the narrative
Every answer traces back to a read-only query the compiler verified. Where it cannot, the fallback is labelled plainly rather than dressed up as the same thing.
02
Ask like a human, answer like an analyst
A non-technical person should feel fluent here without losing any of the rigour an analyst would insist on. Both halves of that sentence are load bearing.
03
Access comes from the session, not the prompt
Who you are is resolved from your membership when the request arrives. Nothing typed into a chat box can widen what you are allowed to see.
04
Nothing new weakens the guarantee
New surfaces may extend the semantic layer. None of them get to route around it because it was inconvenient that week.
05
Claim only what the product does
No invented benchmarks, no borrowed customer logos, no certifications we have not earned. The connector wall on this site is a list of things it connects to, and nothing more.
Built by Gateway Group.
Gateway Group is a global software engineering house. iDash comes out of the practice that has spent years building data platforms for other companies.
Gateway Group builds software for companies that need it to work on the first day it ships. That work is where iDash started: the same conversation, on repeat, in one client engagement after another. The dashboards exist, the warehouse is fine, and somebody senior still cannot get a straight answer without a person in the middle.
iDash is the tool we kept wishing those teams had. It carries the engineering habits that came with it: read-only by construction, credentials encrypted before they are stored, correctness enforced where it can be tested rather than where it can be prompted.
The people building it.
Engineers, data people and designers who have shipped this problem before, for other companies, one ticket at a time.
The team is deliberately small and sits across the compiler, the agent and the interface, because the interesting bugs live in the seams between them. The person who writes the dedup planner is the person who reads the refusal message out loud to check it makes sense to a finance analyst.
We hire through Gateway Group, and we look for the same instinct every time: a preference for being provably right over being impressively fast.
See it against your own data.
Bring a read-only replica and a question your team already argues about.