Skip to main content

The computation pipeline

The function runSevenStepWizard in shared/api-core/src/lib/zeqWizard.ts is the spine of the framework. Its header states the contract plainly:

EVERY query must pass through this wizard. No bypass is possible. Steps run sequentially; each step records its output in protocol_steps[].

This page walks the seven stages as they actually execute, with the real behaviour of each. The verbatim protocol statement — the seven steps as doctrine — lives at the 7-step protocol; this page is the engineering view of how the code runs them.

The seven stages​

1 SELECT   resolve the operator set            → zeqCompute.ts
2 BIND     bind NIST CODATA 2018 constants      → nistConstants.ts
3 VALIDATE dimensional engagement + range checks → dimensions.ts
4 COMPUTE  domain-specific closed-form physics   → zeqSolvers.ts
5 VERIFY   check the ≤0.1% precision bound        → (inline)
6 PULSE    stamp the HulyaPulse / Zeqond clock    → zeqCompute.computePulse
7 RETURN   assemble the signed, transcripted result

1 — SELECT​

Resolves which operators answer the query. Three paths, in priority order: an explicit operator list ({"operators":["GR37"]}), a seeded cross-catalogue selection (when the caller passes query tokens + an HMAC seed — the path the wizard homepage uses), or the legacy intent-aware selector. When the caller names an operator but no domain, the operator's own registry domain drives the dispatch — so compute NM19 runs through Newtonian mechanics, not whatever domain sorts first. Full detail: operator selection.

The step records the chosen operators, the resolved domain, the selection mode, and the size of the catalogue it ranged over.

2 — BIND​

Binds the physical constants the selected domain needs, from a fixed NIST CODATA 2018 table, via bindConstants(domainGroup). A relativity compute binds G and c; a thermodynamics compute binds k_B and R. The step records the CODATA release and the constants bound. Full detail: binding constants.

3 — VALIDATE​

Two checks. First, range sanity (validateInputs): non-finite inputs are zeroed, negative mass is taken absolute, super-luminal velocity is clamped to 0.999c, negative temperature is clamped to 0 K. Second, and more important, dimensional engagement (checkDimensionalEngagement): if the caller supplied inputs but none of them dimensionally engages the selected solver, the compute is rejected before it runs with DIMENSIONAL_MISMATCH (HTTP 400). This stops the failure mode where {"temperature": 300} sent to a quantum operator returns a confident energy computed entirely from defaults — a right-looking answer to a question never asked. Full detail: dimensional validation.

If VALIDATE rejects, nothing downstream runs; the wizard returns a structured rejection.

4 — COMPUTE​

Dispatches by domain prefix to a closed-form solver (computeByDomain). Each solver evaluates real physics — r_s = 2GM/c², E = hν, F = ma — over the bound constants and validated inputs, and returns a value, a unit, an uncertainty, and the equation it used. Full detail: the solvers.

5 — VERIFY​

Checks the solver's result against the ≤0.1% precision bound: precisionActual = uncertainty / |value|, pass if ≤ 0.001. A non-finite value is reported honestly as no_solution (degraded), not as a precision failure. Crucially, the step documents that the precision bound checks the solver's numeric accuracy — it is not compared against the KO42 modulation, because the two have different dimensions. Full detail: precision & proof.

6 — PULSE​

Stamps the result onto the clock. computePulse(nowMs) returns the current zeqond (floor(unix_ms / 777)) and the phase within the tick, and reports the bounded KO42 modulation R(t) = S₀·[1 + α·sin(2π·f_H·t)] with S₀ = 1. The clock is computed, not received. Full detail: synchronisation.

7 — RETURN​

Assembles the structured result: the bare solver value, the protocol_steps[] transcript, the generated master equation, the operator objects, the clock stamp, and the metadata (CODATA release, SDK version, and the registry version — sha256 of the operator registry, so a reader knows exactly which catalogue produced the number).

The value you get back is the bare physics​

A deliberate design decision (the 2026-06-03 "Phase 2" change) is worth calling out: the top-level value is the bare solver output — textbook physics, untouched. The KO42 carrier R(t) = 1 + α·sin(…) is protocol bookkeeping, reported in its own labelled fields (result.carrier, result.modulated_value), never silently multiplied into the physics. Earlier versions multiplied the answer by a time-dependent factor of up to ±0.1%; that is gone. When you quote a Zeq value, you are quoting the physics, not the physics times a clock term.

Three honest verdicts​

Every result carries a verification field that is never silently absent. It is exactly one of:

  • verified — a dedicated closed-form solver produced a finite value inside the numeric-accuracy bar. Re-runnable math.
  • unverifiable — no finite value (a generic pattern-match miss, missing inputs) or a degraded mode (e.g. the VX quota fallback). Never presented as truth.
  • disputed — an independent verifier node re-computed and disagreed. Wired through the cross-node attestation path.

A framework that returns a number is easy. A framework that tells you, on every call, whether that number is trustworthy is the point.

The whole transcript ships​

Because every stage writes into protocol_steps[], the envelope you receive is a complete record: which operators, which constants, which dimensional verdict, which solver, the precision actual, the clock stamp, the registry version. You do not have to trust a summary — you can read the derivation and, with the signed envelope, replay it.

No bypass. Seven stages. A transcript on every result.