For teams shipping AI analytics
Test your AI analyst against an answer key that is right by construction.
You state the numbers: MRR from $50k to $200k, 2% monthly churn with a spike in Q3. Misata builds the company data to them, every foreign key valid, then reads each number back from the delivered tables in SQL. The key is the SQL and the value of every metric, every month, so an AI analyst, a text-to-SQL model or a dashboard built from a prompt can be graded against the truth rather than against someone’s labels.
How it is tested today
Gold answers written by hand
An expert audit found errors in 52.8% of the gold answers in BIRD Mini-Dev, a standard text-to-SQL benchmark.
Jin et al., 2026A test company built by hand
Tens of thousands of lines of generators for one world, and then something else to grade the answers against it.
A model as the judge
A second model’s opinion of the first one’s answer, with a rubric someone has to keep right.
Misata’s answers are not labelled. The data is built to them: each number is set before a row exists, so there is nothing to annotate and nothing to judge.
What you grade against
The answer key, as data
answer_key.json and a long CSV: each metric’s SQL, its value in every month, what was stated and the tolerance it is held to. From the dataset’s Story tab, its download, or GET /runs/{id}/answer-key.
Questions with proven answers
Questions drawn from the key, each with its gold answer, the SQL that reads it, and the wrong answers its usual misreadings give. questions.jsonl, and the same seed asks the same questions.
A checker that says why
Paste the SQL an analyst wrote: when its numbers differ from the key, the checker names the cause and proves the fix by running the corrected query. Paste the numbers a chart shows, and it says which metric they are, or which misreading of it.
A certificate anyone can open
Every stated number, held in the data and read again in SQL, the laws that tie the tables together, and a digest of each table, on a page you can share.
A wrong answer, told why
A dashboard wrote its churn over every account in the table:
SELECT month, leavers * 1.0 / (SELECT count(*) FROM accounts) AS churn FROM months
Over every one of the accounts, not those still in
The query divides each month’s leavers by all the accounts in the table: those begun after the month and those gone before it included. The KPI divides by those in at the month’s start.
The checker’s verdict on the demo dataset, word for word.
Build the key for your own story
In Studio you start from the SaaS story, change its numbers, and download the answer key with the data. Studio is invite-only for now; meanwhile, see a query checked against the demo dataset.
Evaluating an agent that acts in a whole business rather than one that answers questions? Worlds for agents and evaluation environments.