Natural-language analytics
Ask your data a question in plain language, and see the query and the rows behind the answer.
Analysis is gated on the few people who know the schema #
The people with the questions and the people who can express them in SQL are rarely the same people. Every request becomes a ticket, and the queue sets the pace of the organisation's understanding of itself.
Self-service tools push the schema problem onto the asker. Text-to-SQL tools guess at it. Both fail in the same expensive way, and it is the failure mode that decides whether this technology is allowed anywhere near a decision.
Why it is not trusted
- Answers with no query attached, so they cannot be checked or reused.
- A generated query that quietly joins the wrong way and returns something believable.
- Questions that need data from three systems, so nobody asks them.
- Analytical tools that see rows the asker would never be allowed to query directly.
An answer you cannot trace is an answer you cannot defend. Every one here shows the query and the rows it came from.
A planner that understands the shape of your data, and shows its work #
Atom continuously infers a map of your tables, columns, sensitivity and relationships. An agentic planner reasons over that map to turn a plain-language question into safe, permission-aware SQL, and will ask a clarifying question or decline rather than guess.
Every answer comes with the query that produced it and citations back to the data it used. Because the same permission path governs generated queries as governs every other read, a question can never return rows the asker could not have queried themselves.
- Atom
- The SQL engine, the inferred schema graph, natural-language planning, federation and the safety rules on every query.
- Anima
- The reasoning models behind planning and explanation, served privately so your schema and results stay inside the boundary.
- Application Framework
- Dashboards, data explorers and embedded assistants that put the answers where the work happens.
What makes a generated answer trustworthy #
An answer is only useful if you can see how it was derived and be sure it respected the asker's access.
How a question becomes a query
The planner reads your real data model rather than a semantic layer somebody has to maintain.
Planning over an inferred graph
Relationships and joins are discovered continuously, so the planner traverses your real data model without a hand-mapped semantic layer to maintain.
Clarify, or decline
Where a question is genuinely ambiguous the planner asks; where it cannot be answered safely it says so. Neither failure mode is a confident wrong number.
What a generated query is not allowed to do
The limits are in the execution path, not in a prompt asking the model to behave.
Safe by default
Generated and hand-written queries alike are read-only by default, with mandatory limits and bounded cost, so an ambiguous question cannot become an outage.
The asker's permissions, in the query
Row filters, column masks and deny decisions are applied during execution on every path, so analytics cannot become a way around access control.
How far a question can reach
Most real questions cross systems, and most tools quietly stop at the edge of one.
One question, several systems
External PostgreSQL, MySQL and ODBC databases register as native tables and work is pushed down to them, so questions that span the lakehouse and systems of record are ordinary.
Beyond questions
On-demand forecasting, anomaly detection and record similarity train against the same federated data, with model-skew detection and bounded read budgets, and never leave the platform.
What your analysts keep
Nobody has to abandon the tools they are fluent in to get a traceable answer.
Your existing clients still connect
The lakehouse answers on the PostgreSQL wire protocol and on Arrow Flight SQL, so the warehouse clients, dashboards and spreadsheet tools your analysts already drive can query it as they would an ordinary database. No new reporting stack, and no nightly extract to keep in step.
Diagrams that explain the data
Auto-generated, focusable schema and relationship diagrams let someone understand a dataset's structure before they trust an answer drawn from it.
What a reviewer can establish about any answer #
Anyone who has to stand behind a number asks the same short list, whether they call it model risk, model validation or simply due diligence. None of this is a compliance product; it is the material an oversight function needs to do its own job.
- Which query produced this number?
- The generated query is returned with the answer. It is read-only by default, with mandatory limits and bounded cost, so a reviewer can read it, judge it and run it again rather than trusting the figure.
- Which rows did it actually read?
- Answers cite the exact data used, back to the source. Where the question spanned an external database, the pushed-down work is part of the same picture.
- Can the same answer be reproduced later?
- Every ingestion, transformation and query is hashed, timestamped and recorded as immutable lineage, so the derivation of a figure is reconstructable rather than remembered.
- Who asked, and what were they entitled to see?
- Each access lands in a canonical, redacted audit ledger correlated to the identity and the query behind it, and the asker's row filters and column masks were applied during execution rather than afterwards.
- What does it do when it is not sure?
- It asks a clarifying question, or it declines and says why. The one thing it does not do is produce a plausible figure it cannot support.
Where the analysis runs #
Queries execute next to the data they read, including data that is federated rather than copied.
- Managed sovereign cloud
- Operated for you, inside your boundary.
- Private cloud
- Close to the warehouses and databases you federate.
- On-premises
- For data that cannot leave your own network.
- Multi-site
- Analysis local to each region's data.
Point it at a real schema
The honest test is a messy production schema and the questions your analysts get asked most often. We will show you the query behind every answer.