You have a question. "How much revenue came from referrals last month?" The distance between that sentence and the answer is usually a person who knows SQL, the exact table, and the exact spelling you used when the data was loaded. That last part is where most natural-language tools quietly fall apart.

Event Horizon Data now lets you ask in plain language, and it closes that gap in a way that is worth being specific about.

It matches the values that are really in your data

Ask "revenue from the referral channel" and a typical assistant writes WHERE channel = 'referral' and hopes. But your data might store it as Referral, or ref, or, if your team works in Portuguese, Indicação. The query runs, returns zero rows, and nobody notices the filter was quietly wrong.

Ours doesn't guess. It builds a small index of your own distinct dimension values and matches your phrase against them, so "receita do canal indicação" resolves to the referral that is actually in your column. When it makes that match, it tells you it did, and from what. The question you asked and the data you have finally speak the same language.

How it works, briefly

Behind the plain-language box are two small indexes, both built from your own tenant and kept on our machines. One maps a question to the right columns, so asking "how much did we bring in" finds your revenue column. The other maps a phrase to a real stored value, so "word of mouth" resolves to the referral your data actually holds. With those two, the assistant writes SQL over your real schema and your real values, and that SQL then goes through the same checks any query does before you ever see it.

What it does not do matters just as much. It does not read your rows to answer you, and it does not send your data to a model to be summarised. Your data stays in the warehouse; the assistant only ever produces a query that runs there, on the numbers themselves. That is why "how much revenue from referrals last month" comes back as the exact sum it is, not a plausible-sounding guess.

It only shows you what it can prove

The assistant never runs anything on its own. It drafts a query and hands it to you for the SQL Explorer, and while it works you see the real stages, interpreting, writing, validating, instead of a spinner. The SQL only appears once it has passed the same validation and cost check every query on the platform goes through. You never see a draft that looks confident and turns out to be invalid a second later.

And when it can't match a value, it says so out loud rather than inventing one. "That value isn't among your channel values, so it was left as written, check that filter" is more useful than a clean-looking query that silently means nothing.

The AI runs on our own machines

This is the part we care about most. The language model behind this feature runs on our own infrastructure, not OpenAI, not Anthropic, not any hosted AI API. Your question and your schema are processed locally and never leave the platform. Where the assistant matches your phrase against your own values, that index is built and stored inside the platform, isolated to your tenant, and it never reaches a third party.

Most "AI for your data" ships your data to someone else's model. This one doesn't. There is no additional sub-processor for the AI, which is why our DPA and privacy policy can say so plainly.

Nothing skips the guardrails

The drafted query is exactly that, a draft you review and submit through the governed path. It runs through the same fail-closed tenant scope, the same cost gate, and the same reconstruction every query does. The assistant cannot reach another customer's data, and it cannot run raw SQL around the checks. We proved that the way we prove everything about isolation: we red-teamed this feature before shipping it, with a second tenant holding values yours would never see, and confirmed one customer can never reach another's, that a request cannot spoof its own tenant, and that a resolved value cannot escape the guardrails.

You decide what gets indexed

A dimension might hold something personal, a name, an email. You can mark any column so its values are never indexed, and doing so erases the copy that was already there rather than just stopping new ones. That control exists because a red-team of this feature found it was missing, and we closed it before the feature went live. That is the whole posture we keep coming back to: check, don't just trust. The report is on our security page.

That's what we set out to build: your words, your data, your machines. Ask it something.