FeatureQL and language models

Much FeatureQL is written by language models. This page describes the pattern that the design supports, and which properties of the language help.

Deterministic core, model at the edges

A model works at two places. First, it turns a question into a FeatureQL query by choosing which published features to compose. Last, it turns a result into an explanation.

Everything in between is deterministic. The type system refuses invalid combinations, the registry validates dependencies, the compiler emits SQL, and the engine computes the number. The model writes no join and reads no row.

The same pattern covers two uses:

• Analytics. An assistant answers a business question by composing published features.
• Backend rules. The same query, persisted and wrapped in a PREPARED_STATEMENT, is a served rule. Nothing is rewritten between the analytics answer and the production endpoint.

Properties that help a model

A vocabulary it can query. SHOW FEATURES, SHOW FUNCTIONS and SHOW TESTS list what exists. An offline help corpus holds signatures, common mistakes and runnable examples. Local MCP tools (validation, diagnosis, execution, help) run without sending row data anywhere.

A smaller search space. A query is a flat set of named bindings, not a nested tree. A mistake affects one named feature, and the error names that feature.

Checks before execution. A wrong join, a wrong unit or a sum across a non-additive axis fails to compile. With generated SQL, the same mistakes return a number. See Semantic contracts .

Errors written for a repair loop. An error carries a stable code, a location, the feature it concerns and, where one exists, a repair that compiles. The additivity error names the axis and gives MAX_BY(SNAP[STOCK], DAY) as a replacement. An agent that retries with that expression is following the compiler, not guessing.

No non-terminating query. The graph is acyclic and iteration is bounded. See Scopes and termination .

Fewer tokens. A published CUSTOMER_LTV is one name. The equivalent SQL is many lines. A registry of published features gives an assistant more to work with than a wide schema does.

Proposed changes can be evaluated. A VARIANT differs from its base in exactly the dependencies it replaces, and the result is type-checked again. See Composition and substitution .

What review looks like

The model's output at the first edge is a FeatureQL query: named features, typed, with dependencies that can be inspected step by step. Its output at the last edge is an explanation of a number it did not compute. Both are text a person can read.

The reviewer's question changes from "is this SQL correct" to "is this the right definition".

Limits

The compiler establishes that a feature is well formed and deterministic. It does not establish that the feature answers the question that was asked. That part is reviewed by people.

The comparison with generated SQL is a design argument. It has not been measured.

How much of a loop runs without a person is a release decision. See A loop for improving the business .