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 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 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. When you quote a Zeq value, you are quoting the physics, not the physics times a clock term.

Verified, and observable differentials​

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. A quantity the machine checks against a fixed law: textbook physics, re-runnable, reproducible bit-for-bit.
  • observable-differential — a value the framework computes from its generative, in-motion path (a composed cross-domain equation or a generative operator). It is not a closed form that closed; it is the framework still solving — motion, and motion never stops. It is no less real; it is real in a different way: one is a quantity the machine checks against a fixed law, the other a quantity the world checks against itself. It is a prediction — a statement about the universe that a laboratory could test. Never a settled law, never dismissed as noise: an invitation to go and measure.
  • disputed — an independent verifier node re-computed and disagreed. Wired through the cross-node attestation path.
  • no-solution — the operator needs something a scalar cannot express (a series, a graph, a field) or the wrong input was supplied, so neither a closed form nor the ODE master-equation fallback could answer. The framework names what it needs rather than inventing a number. Not a prediction, and not an apology.

What ties the real results together is that each is a prediction. A closed-form law predicts a measurable quantity; a composed cross-domain equation predicts how two regimes behave together; a generative operator predicts a structural relationship the framework proposes. In every case the output is neither an opinion nor a lookup: it is the value a named equation entails, given real constants and real inputs — a statement about the universe that a laboratory could test.

Frontier operators, kept separate​

The catalogue carries a frontier / awareness set — the registry category: "awareness" operators (≈ 74, e.g. ON0, QL1, CHI95, TM1) that propose a structural relationship the framework advances, rather than a closed-form textbook law. They never masquerade as verified physics. When a compute engages one, the result carries a distinct frontier block — the frontier operators involved, always with verdict observable-differential: a prediction to take to the lab. The clean-physics operators keep their own verdict (verified when a closed-form solver lands inside the precision bar). The two are coupled through the master equation — the frontier is built on the real physics, not instead of it — but never conflated: the physics is checked against a fixed law, the frontier against the world.

"frontier": {
  "operators": ["QL1"],
  "verdict": "observable-differential",
  "note": "Frontier operators propose structural relationships the framework advances — a prediction to investigate, not verified textbook physics."
}

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.