Your data already knows. Getting it out takes three days and an analyst.

It isn't a replacement, and if your dashboards answer your questions you don't need me. The gap those tools leave is the question nobody built a dashboard for — which is most questions, because dashboards answer what you anticipated, not what you're wondering about on a Tuesday.

The other gap is the queue. Every ad-hoc question goes to a data analyst, gets prioritised behind four others, and arrives three days later when the decision has moved on. This doesn't replace your BI tool; it removes the queue in front of it. And it can be built on top of your existing semantic model if you have one — Looker's LookML or a dbt metrics layer is a real head start.

Possibly, and the review will tell you honestly. But "our data is a mess" is what every company says, and it's usually less fatal than it sounds — what matters isn't tidiness, it's whether the numbers you care about can be derived reliably from somewhere.

The genuine blockers are different: no single source for a core entity like customer, or transformations that live only in someone's spreadsheet. Those need fixing first, and I'd tell you that in week two rather than month four.

Four ways, all visible in the demo above. Answers only compose from defined metrics, so an undefined concept produces a refusal instead of a guess. Every answer shows the definitions it used. Every answer shows the query. And the system flags caveats — incomplete periods, unusual outliers, definition changes mid-range — before you quote the number.

Then there's measurement: the evaluation set runs continuously, so a drop in accuracy shows up as a number rather than as someone's embarrassment in a board meeting.

Only if they could already query it directly. Permissions are enforced at the query layer against your existing access model — the system can't return rows or columns the asker isn't entitled to, and it says so rather than pretending the data doesn't exist.

Every question and every answer is logged, so you can audit what's being asked as well as what's returned.

Your schema and definitions go to the model so it can compose a query. Whether your data does is a choice: the query can execute entirely within your warehouse and return only the aggregate result for phrasing, or not touch an external model at all if you run a local one.

That decision gets made in week one and written into the agreement, with contractual no-training terms where an external provider is involved.

It breaks, loudly and immediately — which is the correct behaviour. The definition layer references specific tables and columns, so a rename fails a validation check rather than silently returning a wrong number.

The ongoing option exists largely for this. Schemas drift constantly in a growing company, and an unmaintained semantic layer decays into exactly the confusion it was built to fix.