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

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, 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, 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:

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.