# RFQ1: Building a Relation-First Query Language for Project Venus

> Project Venus explores whether a constrained query language can retain the expressive power needed for analysis without giving a language model direct control of SQL.

Published: 2026-08-13T10:00:00Z
Updated: 2026-08-13
Author: George Pullen (Author, MLX)
Category: Research
Tags: project-venus, rfq1, structured-generation, xgrammar, sql, language-models
Canonical URL: https://mlx.systems/blog/rfq1-relation-first-query-language

## TL;DR

- RFQ1 places relation selection before projection and represents the rest of a query through ten clauses with a closed set of constructors and operators.
- XGrammar can mask structurally invalid tokens during generation, while the parser and broker remain responsible for issued handles, aliases, types and semantic requirements.

---

Large Language Models are increasingly asked to answer questions using structured business data. Direct SQL generation requires the model to choose physical relations, construct joins, use the correct dialect and preserve organisational scope. Narrow semantic APIs reduce this surface, but can lack the expressive power required for complex analysis.

In [Project Venus](/research), we are exploring RFQ1: a model-facing, relation-first query language. Rather than executing RFQ1 directly, MLX parses it into a typed query object which a deterministic broker can validate and compile into parameterised PostgreSQL.

RFQ1 follows a wider line of structural text-to-SQL research. [ASTormer](https://arxiv.org/abs/2310.18662), for example, decodes SQL as an abstract syntax tree while incorporating node types and tree positions into the Transformer. RFQ1 instead exposes a fixed, relation-first surface intended for grammar masking and deterministic compilation.

## The Ten Clauses

Every query includes the same ten ordered clauses:

| Clause | Function |
| --- | --- |
| `FROM` | Defines CTEs, the primary source and any joins. |
| `WHERE` | Filters individual rows before grouping. |
| `GROUP_BY` | Defines how rows are combined into groups. |
| `HAVING` | Filters those groups after aggregation. |
| `WINDOWS` | Defines partitions and orderings for functions such as rank, lag or running totals, without collapsing the original rows. |
| `SELECT` | Defines the expressions returned by the query. |
| `DISTINCT` | Determines whether duplicate output rows are removed. |
| `ORDER_BY` | Specifies output order and the position of null values. |
| `LIMIT` | Restricts the number of returned rows. |
| `SET_OPS` | Combines complete queries using `union`, `union_all`, `intersect` or `except`. |

Placing `FROM` first requires the model to establish the relation graph before projection. This does not guarantee correctness, but makes relation selection explicit.

## Expressions

Consider the following filter:

```text
BIN(eq,COL(activity,col_...state),LIT(text,"completed"))
```

`BIN` constructs a binary expression containing an operator and two operands. `eq` represents equality and is later compiled to `=`. Other permitted operators include comparisons such as `gt`, arithmetic such as `add`, and logical operations such as `and`.

`COL` refers to a column through a source alias and an opaque handle issued during catalogue discovery. `LIT` introduces a typed literal. In this example, `completed` is text; the broker converts it into a bound parameter rather than inserting it directly into SQL.

## Restricting Generation with XGrammar

RFQ1 uses Extended Backus–Naur Form (EBNF), a notation for defining valid syntax. XGrammar compiles this grammar against a model's tokenizer to determine which tokens remain valid after each generated prefix.

At each step, the model produces a logit for every token in its vocabulary. XGrammar masks structurally invalid tokens by setting their logits to negative infinity, after which the next token is sampled from the remaining set. Following `BIN(`, for example, only token sequences beginning a permitted binary operator can remain available. The selected token then advances the grammar state and a new mask is produced.

This is not a fixed allowlist attached to each clause. A token is permitted when its decoded bytes leave at least one valid continuation through the grammar; consequently, a keyword may occupy one token in one model and several in another.

The permitted language is therefore decided by the EBNF and its closed capability lists. Nevertheless, grammar membership is only one form of correctness. The parser and broker must still establish that handles were issued, aliases are bound, types and function arities are valid, and the query satisfies its semantic requirements. RFQ1 separates these responsibilities: the model proposes a structured relational program, while deterministic systems retain authority over validation and execution.