Execution model

QQL deliberately separates language correctness from backend execution.

Stage	Input → output	What can fail
Parse	source → typed Stmt	syntax, duplicate/out-of-order clauses, invalid literals
Rewrite	Stmt → policy-safe Stmt	unsupported injection target or operator
Prepare	Stmt + schema/embedder → prepared statement	ambiguous vector role, missing model, embedding failure
Plan	prepared statement → PlannedOperation	unsupported semantic combination
Dispatch	plan → REST, gRPC, or edge	backend capability, transport, Qdrant response

QQLA schema-resolved text queryTry in playground↗

QUERY TEXT 'release safety' FROM engineering_docs
USING semantic_v2
PARAMS (hnsw_ef = 96, exact = false)
LIMIT 12;

USING semantic_v2 names the vector. During preparation, the runtime reads the collection schema to determine whether that vector is dense, sparse, or multivector. Offline compilation can use AS DENSE, AS SPARSE, or AS MULTI when no schema is available.

Scripts and batches

Parser::parse accepts exactly one complete statement. Parser::parse_all accepts a semicolon-delimited script. Host arrays are a separate batch axis: each array element may itself be a statement or script.

The executor parses a string as a script automatically and can wire-batch compatible adjacent operations while preserving result cardinality.

Transport neutrality

The plan IR is authoritative. REST serializes it to OpenAPI routes and JSON; gRPC converts it to Qdrant protobuf types; edge evaluates the supported subset in process.