How a compute runs

A compute is not a black box. This page traces one real request all the way through the CPU — from the JSON you POST to the signed number you get back — naming the function that runs at each step and showing the actual values it produced. Everything below is from this call, which you can run yourself:

curl -sX POST https://zeqsdk.com/api/zeq/compute \
  -H "Authorization: Bearer $ZEQ_KEY" -H "Content-Type: application/json" \
  -d '{"operators":["KO42","GR37"],"inputs":{"mass":1.98892e30}}'

GR37 is the Schwarzschild radius, $r_s = 2GM/c^2$. The mass is the Sun's. The answer is 2954.0077 m, and the rest of this page is exactly how those digits were produced.

The shape of the engine

One request runs a fixed seven-step pipeline (shared/api-core/src/lib/zeqWizard.ts). There is no degraded path — physics always runs the full wizard:

$$\text{parse} \rightarrow \underbrace{\text{SELECT} \rightarrow \text{BIND} \rightarrow \text{VALIDATE}}_{\text{set up the problem}} \rightarrow \underbrace{\text{COMPUTE}}_{\text{do the maths}} \rightarrow \underbrace{\text{VERIFY} \rightarrow \text{PULSE} \rightarrow \text{RETURN}}_{\text{check, stamp, sign}}$$

Each step returns a protocol_step row in the response, so the trace below isn't a diagram of what might happen — it's the object the machine actually emitted, step by step.

Step 1 — SELECT: which operators, which domain

The engine resolves each operator ID against the live registry (1,606 operators, 65 categories). GR37 resolves to the General Relativity domain (prefix GR); KO42 is the mandatory modulation operator, always operatorChain[0]. An ID that isn't in the registry is refused (UNKNOWN_OPERATOR) — never guessed. The real step-1 detail from this call:

{ "domain": "General Relativity", "prefix": "GR", "operators_selected": ["KO42","GR37"],
  "primary_operator": "GR37", "total_domain_operators": 24, "total_catalogue": 1606,
  "selection_mode": "explicit" }

selection_mode: "explicit" means you named the operators, so the engine ran exactly those. (If you describe a problem in words instead, this is where intent-matching picks the operators — but a named ID is always honoured verbatim.)

Step 2 — BIND: attach the constants

Physics needs numbers for its constants, and they must be the same numbers everywhere or two nodes would disagree. BIND attaches the CODATA 2018 constant set — 16 values on this call — from one source of truth. The ones $r_s = 2GM/c^2$ actually uses:

$$G = 6.6743\times10^{-11}\ \tfrac{\text{m}^3}{\text{kg}\,\text{s}^2}, \qquad c = 299{,}792{,}458\ \tfrac{\text{m}}{\text{s}}$$

Also bound here are the clock constants — $\alpha_K = 10^{-3}$ and $f_H = 1.287000000001287$ Hz — and the KO42 metric tensioner ($ds^2 = g_{\mu\nu}dx^\mu dx^\nu + \alpha\sin(2\pi f_H t)\,dt^2$), which is attached to the dynamics here and matters for integrated (ODE) problems. For a closed-form algebraic law like GR37 it rides along without perturbing the arithmetic — a fact the engine is careful about, and which the VERIFY note calls out explicitly below.

Step 3 — VALIDATE: dimensional sanity, real inputs only

Before any arithmetic, the engine checks the inputs are dimensionally coherent for this operator (shared/api-core/src/lib/dimensions.ts). A mass where a length belongs is rejected here rather than producing a confident, wrong number. Missing a required input is treated the same way — it surfaces as an explicit error next to value, not as a fabricated result. This is the honesty contract enforced before compute, not after.

Step 4 — COMPUTE: the actual number, on the CPU

This is where the float64 arithmetic happens. The engine dispatches by domain prefix (computeByDomain(prefix, inputs, constants, operators) in zeqSolvers.ts) to the GR domain solver, which evaluates the closed form directly:

r_s = 2 · G · M / c²
    = 2 · 6.6743e-11 · 1.98892e30 / (299792458)²
    = 2954.007736491099   (IEEE-754 double)

The step-4 row is literally that:

{ "mode": "full", "solver": "GR domain solver",
  "value": 2954.007736491099, "unit": "m", "equation": "r_s = 2GM/c²" }

Two things worth seeing plainly:

• The number is standard physics. 2GM/c² with CODATA constants in double precision. No "Zeq magic" enters the value. The framework's job is to run the right named formula with the right bound constants and prove it did — not to invent a different arithmetic.
• The solver reports its own uncertainty. A closed-form solver returns the value and a numeric-accuracy bound — here $|value|\times10^{-5}$, so uncertainty: 0.029540077 on 2954.0077 m. That bound is what the next step tests against.

Closed form vs. the ODE fallback

Not every one of 1,606 operators has a hand-written closed form. The dispatch has two honest outcomes (mapped exhaustively in the coverage map):

1. A dedicated solver exists → it evaluates the operator's real formula directly, as above. These are exact algebraic/analytic evaluations in float64.
2. No closed form matches → the call routes to solveGeneric, which first tries ~16 universal formulas and, if none fit, numerically integrates the HULYAS master equation with a 4th-order Runge–Kutta stepper (rk4Integrate in zeqSolver.ts). It returns a real, deterministic value — and stamps the result with a visible NUMERICAL FALLBACK disclosure so you always know a closed form was not used. It never fakes one, and never returns a silent NaN.

The RK4 core is the textbook method, reducing the 2nd-order field equation to a 2-vector $[\varphi, \dot\varphi]$ and stepping it:

$$\varphi_{i+1} = \varphi_i + \tfrac{\Delta t}{6}\left(k_1 + 2k_2 + 2k_3 + k_4\right)$$

Which path ran is never hidden — see the solvers for the ODE engine in depth.

Step 5 — VERIFY: is the result inside the precision bound?

The engine tests the solver's own uncertainty against the 0.1% bound:

$$\text{precision}_\text{actual} = \frac{\text{uncertainty}}{|\text{value}| + 10^{-300}} \le 0.001$$

On this call, $0.029540077 / 2954.0077 = 1\times10^{-5}$ — comfortably inside. Real step-5 row:

{ "precision_target": "≤0.1% (0.001)", "precision_actual": 1e-05, "precision_ok": true,
  "note": "precision bound checks the solver's numeric-accuracy bar; the KO42 modulation is
           protocol bookkeeping reported in step 6 — the two are not compared (different dimensions)" }

Read that note twice — it's the single most misunderstood thing about the engine. The precision bound measures the solver's numerical accuracy, not the clock modulation. They have different dimensions and are never compared. If a solver's uncertainty ever exceeds the bound, the step is flagged warn and (per Rule 6) a metric shift can be recommended — the result is never silently passed off as precise.

Independently, the engine also re-evaluates the cited closed form on a separate code path (recompute.ts) and checks the two agree — a computed answer that its own formula can't reproduce is caught here.

Step 6 — PULSE: stamp it to the clock

Only now does the HulyaPulse enter, and only as a timestamp, not as part of the physics. The engine samples the clock from a single Date.now():

$$\tau = \left\lfloor \frac{t_{\text{ns}}}{777{,}000{,}777} \right\rfloor, \qquad R(t) = S(t)\,[1 + \alpha_K \sin(2\pi f_H t)]$$

with $S(t)=1$ for a stamp. Real step-6 row:

{ "hulyapulse_hz": 1.287000000001287, "zeqond": 2296532592, "phase": 0.0478,
  "R_t": 1.000296, "S_t": 1, "alpha_K": 0.001,
  "note": "TIME-MODULATION bookkeeping, NOT the KO42 metric tensioner …" }

The carrier $R(t) = 1.000296$ is a ±0.1%-bounded number that encodes when the compute happened. It is carried alongside the answer, never multiplied into the reported physics: the response gives you value: 2954.0077 (the bare physics) and, separately, modulated_value: 2954.8825 (= value × carrier) for anyone who wants the clock-stamped form. How equations combine takes this apart term by term.

Step 7 — RETURN: sign and envelope

The engine assembles the Zeq envelope: the value and unit, all seven protocol steps, the zeqState (operator objects, master equation, masterSum), the result breakdown, and a ZeqProof — an HMAC over operator | result | zeqond that any node can re-verify. meta records the CODATA release, the SDK version, and the registry_version hash that pins exactly which operator catalogue produced this. The number now travels with everything needed to check it was computed honestly, and when.

The whole trace, at a glance

Step	Function	What it did here	Output
parse	route handler	read JSON body	{operators, inputs}
1 SELECT	registry lookup	resolved GR37 → GR domain	primary: GR37
2 BIND	constants charter	attached CODATA 2018 (16 constants)	G, c, …
3 VALIDATE	dimensions.ts	mass is dimensionally valid input	ok
4 COMPUTE	GR domain solver	2GM/c² in float64	2954.007736 m
5 VERIFY	precision gate + recompute.ts	1e-5 ≤ 1e-3, re-eval agrees	precision_ok
6 PULSE	computePulse()	clock stamp at τ=2296532592	R(t)=1.000296
7 RETURN	envelope + HMAC	signed CKO envelope	zeqProof

Total wall time on the node: 1 ms. Nothing here is hidden, nothing is invented, and every value is reproducible with the command at the top.

Read next

• How equations combine — the master sum, the carrier, and multi-operator composition, decomposed from a real envelope.
• What computes what — the measured map of closed-form vs. ODE-fallback coverage across all 65 categories.
• The solvers — the RK4 master-equation engine in depth.
• The honesty contract — compute, ask, or refuse — never fabricate.