Skip to main content

Operator selection (SELECT)

The first thing the pipeline does is decide which operators answer the query. This is Step 1, implemented in zeqWizard.ts with the selection logic in zeqCompute.ts. It is also where the framework is most clearly generative: there is no fixed function per problem, only a catalogue of operators and a way to pick the right ones.

Three selection paths​

The wizard resolves operators by trying three paths, highest priority first.

1. Explicit​

If the caller names operators, they win:

{ "operators": ["GR37"], "inputs": { "mass": 1.98892e30 } }

The wizard matches each id against the catalogue (case-insensitive, up to 10), and uses what it finds. This is the path SDK and CLI users take when they know the operator they want.

2. Seeded cross-catalogue (the homepage path)​

When the caller passes query tokens plus an HMAC seed — the path /api/zeq/wizard/auth-bootstrap uses for the wizard homepage — selection runs selectOperatorsAcrossCatalogue, which ranges over the entire 1,500+ operator catalogue, not just one domain's ~20 operators. It scores every operator by:

  • token signal — a query token hitting the operator name scores ×4, its equation ×2, its description ×1, an exact id match ×3;
  • domain bias — operators in the matched domain get +1.5 (soft, not a hard filter, so a strong cross-domain match can still surface);
  • HMAC-seeded jitter — a per-request value in [−1, +1) derived from the seed, which breaks score ties so two identical queries one Zeqond apart pick different operators.

It then takes the top picks and adds one cross-domain wildcard from outside the matched domain, guaranteeing the master equation is genuinely multi-domain when the catalogue allows it. The seeded jitter breaks score ties, so selection spreads across the catalogue rather than collapsing toward the first operators in the registry.

3. Intent-aware​

If neither path fires, selectIntentAwareOperators scores the matched domain's operators by the input variable names and a scale hint derived from the input magnitudes (planck-scale inputs pull quantum operators; stellar-scale inputs pull gravitational ones). This path is deterministic given (domain, inputs) and serves callers that pass inputs without tokens + a seed.

Domain truth​

A subtle correctness rule lives here. When the caller names an operator but no domain (compute NM19 …), the operator's own registry domain drives both selection and the COMPUTE dispatch. So an explicit NM19 (Newton's second law) resolves to Newtonian Mechanics because that is where it lives, and runs through the right solver — the physics is correct and the precision gate holds. An explicitly passed domain still overrides the operator's home.

The seed never leaves the framework​

The per-request seed is HMAC-SHA256(ZEQ_NODE_SECRET, "zeq.seed.v1|" + zeqond + "|" + queryHash), truncated to 16 bytes. The node holds ZEQ_NODE_SECRET; the client never sees it. So even an attacker who knows the exact query and the timestamp cannot reproduce the operator set — they'd need the node secret that minted the seed. The cleartext query is never logged; only its SHA-256 (queryHash) is, which is what binds a given equation to a given query in the audit trail.

Why "generative" is literal here​

A conventional library exposes one routine per problem. Zeq exposes operators and composes them per request. Two queries that look similar but carry different intent get different operator sets; the same query at two different ticks gets different sets; a query that spans regimes gets a genuinely cross-domain set. The operators are fixed; the composition is generated — which is exactly what the next stages turn into a printed master equation.

The catalogue itself is large: 1,500+ catalogued operators across 60+ physics domains. (The exact count lives only in the live registry's total field and is deliberately never printed on a surface, because it drifts as operators are added — see the operators reference.)

The operators are fixed. The composition is generated, per query, per tick.