Skip to main content

Generative mathematics

A conventional library has a function per problem: one routine for orbital periods, another for kinetic energy, another for photon energy. The mathematics is fixed when the library is written.

Zeq works the other way. It ships operators — named equations with ids — and a rule for composing them into a master equation at request time. The equation that answers your query does not exist until you ask: it is assembled from the operators selected in Step 1, the constants bound in Step 2, and the inputs you supplied. That is what "generative mathematics" means here, and it is literal — you can read the generated equation before you trust the number.

The master equation is assembled, printed, then solved​

buildMasterEquation in shared/api-core/src/lib/zeqCompute.ts composes a structured master-equation document for every compute. It does not summarise — it prints the full composition. The shape it emits:

MASTER EQUATION — GENERAL RELATIVITY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Variables:
  mass                 = 1.9890e+30

Operator Set:
  [GR37] Schwarzschild Radius
        r_s = 2GM/c²

Synthesized Master Equation:
  Ψ(mass) ≡ r_s = 2GM/c²
           ← [GR37] Schwarzschild Radius

KO42 Bounded Modulation (HulyaPulse):
  S₀ = 1.000000e+00  [dimensionless reference]
  R(t) = S₀ × [1 + α_K × sin(2π × f_H × t)]
       = 1.000312e+00  [bounded modulation, |R−1| ≤ α_K]
  where: α_K = 0.001,  f_H = 1.287 Hz,  τ = 0.777 s

When the operator set spans several operators, the "Synthesized Master Equation" becomes an intersection Ψ(…) ≡ ⋂ { … } over the operator equations, and when those operators come from different domains it prints a Cross-domain synthesis: A ⊗ B line — the multi-domain composition the seeded selector deliberately produces. This is the artifact, not a hidden implementation detail: open any tick on the State Explorer and the generated master equation for that exact compute is printed at the top.

The master sum: ground state + modulation​

masterSum.ts breaks the result into its two real terms, so the State Explorer can render a term-by-term table without inventing a decomposition the wizard never computed:

R(t) = S(t) × [1 + α·sin(2π·f_H·t)]
     = S(t)   +   α·S(t)·sin(2π·f_H·t)
        ↑               ↑
   ground state    HulyaPulse modulation (KO42)

buildMasterSum returns the total R(t), the ground_state S(t), the modulation term, and a per-operator rows table — each row carrying its operator id, equation, role (ground_state / awareness / domain), and fractional contribution. The numbers are the ones the wizard actually computed; nothing is back-filled.

KO42 is always in the equation​

Every generated master equation includes the KO42 term — the bounded 1.287 Hz modulation, coefficient α = 10⁻³. It is not optional flavour: it is the substrate term that ties the result to the clock and bounds the modulation to ≤0.1% by construction (see the constants). A master equation without KO42 is not a Zeq master equation. The deeper symbolic form — the HULYAS master equation and its operator-coupling sum — is documented at the master equation; this page is about the runtime equation that the solver actually evaluates.

Why generate instead of look up?​

Three consequences fall out of generating the equation rather than hard-coding it:

  1. Composability. New problems are new compositions of existing operators, not new code. The catalogue grows; the engine doesn't have to.
  2. Transparency. Because the equation is assembled from named parts, it can be printed. A looked-up answer can only show a number; a generated answer shows its derivation.
  3. Verifiability. The same composition rule, run on another node with the same operators and constants, assembles the same master equation — which is what lets an independent party re-derive and verify your result.

The framework generates the mathematics. It does not recall it.