Technical brief

How the semantic validator keeps AI-written queries correct

The semantic validator lets an AI agent write SQL freely, then checks that query against your semantic layer before it runs, so you get the agent’s flexibility and your semantic layer’s correctness guarantee at the same time.

VuonJune 20263 min read

What it does

When you ask a question in plain language, an AI agent writes a SQL query to answer it. Left alone, that query might quietly ignore how your metrics are actually defined.

The semantic validator closes that gap. After the agent writes a query, the validator inspects it and checks every table, join, filter, and measure against the definitions in your semantic layer. A query only runs if it conforms.

Semantic validator

A free-form query, checked before execution

A free-form query, checked before execution

Why it’s useful:

  • Answers stay grounded in your real metric definitions, not the agent’s guesses.
  • The agent is free to write expressive, creative queries instead of being limited to a fixed set of toggles.
  • Incorrect queries are caught before they run, not after a wrong number lands in a deck.

Why this is different from older approaches

Traditional semantic layers, such as Looker or cube.dev, guaranteed correctness by forcing every query through a rigid engine. You picked metrics and filters, and the engine generated the SQL. That guaranteed a correct query, but it also boxed in what you could ask.

When AI arrived, two shortcuts became common, and both have a cost:

Hand the agent the semantic layer files as reference.

The agent reads your definitions as loose context and writes SQL. Because the reference is weak, the agent can drift from your definitions and produce a query that looks right but breaks your rules.

Make the agent fill in the old rigid schema.

The agent generates the structured input the engine expects. This is correct by construction, but it throws away the agent’s ability to write anything the rigid schema can’t express.

The semantic validator takes a third path. The agent writes the SQL it wants, and a separate validation step enforces correctness afterward.

Semantic validator

The validator sits after generation, not inside it

The validator sits after generation, not inside it

How it works

  1. 1

    You ask a question

    in plain language.

  2. 2

    The agent writes a SQL query

    to answer it, with full freedom over how the query is structured.

  3. 3

    The validator inspects the query.

    It parses the query into its underlying structure, its syntax tree, and reads in your semantic layer.

  4. 4

    The validator checks the query against your definitions

    the right tables, the allowed joins, the defined filters, and the correct measures.

  5. 5

    A conforming query runs

    and returns your answer. A non-conforming query is rejected with a reason, and the agent revises and tries again.

Semantic validator

Rejected queries become precise repair loops

Rejected queries become precise repair loops

The agent does what it’s good at: writing expressive queries, and the semantic layer does what it’s good at: defining what counts as correct.