WorkInsighter

Insighter

Live

Ask your data warehouse a question. In English.

A cross-warehouse AI analyst that answers natural-language questions over enterprise data — through a business catalogue a human approved, not through a guess at what your column names mean.

Request a demo

Insighter is deployed into your environment rather than downloaded — it connects to your own warehouses and never moves your data.

What it does

01

Cross-warehouse by design

Oracle and PostgreSQL today, one question spanning both. Dialect differences are handled at translation time rather than pushed onto whoever is asking.

02

A catalogue humans approve

Every metric, join and business term is proposed offline, reviewed by a person, and only then usable at runtime. The model never invents what a number means.

03

Read-only, and provably so

Generated SQL is parsed and checked before execution. Anything that is not a read is refused — not warned about, refused.

04

Answers that show their working

Every answer carries the SQL that produced it and the catalogue entries it relied on, so a sceptical analyst can check it in under a minute.

05

Your data stays where it is

Insighter is deployed into your environment and connects to your own warehouses. Rows are not copied out to a vendor to be answered.

06

Where the questions already are

A web console for exploration, and a Slack app so a question asked in a channel is answered in that channel.

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.

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. If you would like to see it against a seeded demo warehouse first, that is what a demo is for.

More work