The problem it solves
Every company with a warehouse has the same queue: a small number of people who can write the SQL, and a much larger number of people who need the answer. The queue is the product of one fact — knowing what a question means in your schema is expertise, and expertise does not scale by adding a chat box to a dashboard.
Generic text-to-SQL tools fail here for a reason that has nothing to do with
model quality. AMT, TRADE_DT, CPTY_ID — a model can guess at these, and
its guess will be plausible and occasionally wrong. Plausible and occasionally
wrong is the single worst property a reporting system can have.
How it works
Insighter splits the job in two, and the split is the whole design.
Stage one — the knowledge build. Offline, ahead of any question, Insighter inspects the warehouse and proposes a business catalogue: what each table is, which columns carry meaning, how tables join, and what the organisation’s metrics actually compute. The proposals are drafts. A person reviews and approves them, and only approved entries are ever published. When the schema changes, the build runs again and publishing is a merge — approvals already given are not silently thrown away.
Stage two — runtime. A question arrives in English. Insighter resolves it against the approved catalogue, not against raw column names. It plans against the entries it is allowed to use, generates SQL for the right dialect, checks that SQL is read-only, executes it, and returns the answer together with the query and the catalogue entries behind it.
The catalogue sits between the model and the warehouse, which means the model’s freedom stops exactly where the business’s definitions begin.
And then the answer is checked. Before a reply is returned, every number in it is traced back to a value the query actually returned. If a figure appears nowhere in the results — a total the model rounded, a month count it assumed — the answer is rejected and the agent tries again. That check is arithmetic, not a second model marking the first one’s homework.
An answer also says which of the two it is: grounded in an approved metric, or ad-hoc SQL a person should look at before acting on. A system that knows the difference, and volunteers it, is worth more than one that is confident throughout.
Why the constraint is the feature
It would be faster to let a model read the schema and answer directly. It would also be a system nobody in a regulated business could sign off on.
Requiring human approval before a metric can be used costs something once, at build time. It buys an answer that a finance lead can defend in a meeting, and an audit trail showing who agreed that “notional exposure” means what the query says it means. That is the trade Insighter makes deliberately.
Deployment
Insighter runs inside your environment — on your infrastructure, against your warehouses, with your credentials, using a read-only database role. It is not a SaaS you upload data to.
It arrives as one compiled file per platform. There is no Python to provision, no dependency tree to get approved, and no source to read. Setup asks for your licence, your model provider and your warehouse, and checks each one against the real thing before writing anything — including trying to write with the database account, so the read-only guarantee is demonstrated on your hardware rather than promised in a document.
Licences are verified offline, by signature, with no call home. A deployment that cannot reach the internet is a supported deployment, not an exception.
When something is wrong later, a built-in diagnostic checks the whole installation end to end — settings, licence, provider, every warehouse reconnected and re-proved read-only, every catalogue — and prints no secrets, so the output can be sent to us from inside a bank without a screen-share.