Skip to main content

Precision & proof

A number is easy. A number you can trust without trusting the source is the whole point of the framework. This page covers the two pipeline stages that produce that property — VERIFY (Step 5) and RETURN (Step 7) — and the verification stack that stands behind them.

VERIFY — the ≤0.1% bound and the three verdicts​

Step 5 checks the solver's result against the precision bound:

precisionActual = uncertainty / (|value| + ε)
precisionOk     = isFinite(value) AND precisionActual ≤ 0.001    // 0.1%

Three things about this check are deliberate:

  • A non-finite value is not a precision failure. If the solver had no answer for the given inputs (e.g. Bragg's law with no {d, θ}), the step reports no_solution as a degraded status — not a misleading precision warning.
  • The bound is checked against the solver's own numeric accuracy, the uncertainty it reported. It is not compared against the KO42 modulation — the step's own note says so — because the two have different dimensions. Comparing them would be a category error.
  • The bound itself is structural. ≤0.1% holds because the KO42 coefficient α = 10⁻³ bounds the modulation by construction (see the constants), not because a runtime guard clamps a wandering value.

From this, the result gets exactly one verification verdict, never silently absent:

  • verified — a dedicated closed-form solver produced a finite value inside the bound.
  • unverifiable — no finite value, a generic pattern-match miss, or a degraded mode (the VX quota fallback). Never presented as truth.
  • disputed — an independent verifier re-computed and disagreed (see below).

Word size — float64, and why not float128​

Every solver runs in float64 (IEEE-754 double) — the native word size of JavaScript and every CPU the kernel runs on. That is a deliberate engineering choice, not a limitation, and it is worth being precise about why.

The ≤0.1% bound is a tolerance — an amplitude/accuracy budget — not a statement that the answer is correct to 15 digits. For the kind of results Zeq produces, the error that actually matters is truncation / method error (how good the integrator or the closed form is), which sits 8–9 orders of magnitude above float64 rounding. So the real accuracy lever is integrator order, not word size: moving from 2nd-order velocity-Verlet to 4th-order (Yoshida) buys roughly 500× less energy drift at ~1.4× the cost, whereas going from float64 to float128 would shave rounding that is already far below the truncation floor — spending compute to sharpen a number the method error has already blunted.

  • float128 is the wrong lever. Rounding is not the bottleneck; it would be a cost with no accuracy return for these workloads.
  • A dd (double-double, ~106-bit) opt-in exists for one purpose only: chaotic-horizon research, where trajectories in sensitive systems diverge and the extra mantissa buys real horizon before the method error dominates. It is an explicit opt-in, never the default.
  • The multi-body path integrates with RK4 over a state vector stable across the full physical mass range (1e-40 … 1e40), and derivatives are read from the integrator's own state — not from finite differences that would reintroduce rounding.

The honest one-line version: float64 everywhere; accuracy comes from the method, and a result is trustworthy because it is deterministic and re-derivable (below), not because of its word size.

RETURN — signing the result​

Step 7 assembles the result and signs it. There are two layers.

The HMAC envelope (hmacEnvelope.ts) is the symmetric, deterministic layer. Its core is canonicalJson — a JSON encoder with lexicographically sorted keys and no whitespace, so the same logical payload produces the same bytes in every process, regardless of key insertion order. Over those canonical bytes it computes HMAC-SHA256. Keys are 64-hex (32 bytes); comparison is constant-time (timingSafeEqual), never === on a hex string. sealEnvelope binds the signature to a Zeqond by signing {...payload, signed_at_zeqond} — so the seal is bound to when it was made.

The Ed25519 signature (identity.ts) is the asymmetric, publicly-verifiable layer. Each node has an Ed25519 keypair whose private key lives in the ZSC vault (AES-256-GCM at rest) and is never exposed. getNodeIdentity() returns the node's publicKeyHex; signWithNodeKey(payload) signs; verifyWithPublicKey(payload, sig, pub) checks against any node's public key, current or superseded. Rotation creates a key_supersession record signed by the superseded key, so results signed under a superseded key stay verifiable forever.

The result also carries registry_version — sha256(canonicalJson(operator-registry.json)) — so a reader knows exactly which operator catalogue produced the number.

Recompute — bit-for-bit, no database, no clock​

recompute.ts is the standalone re-derivation path, and it is the heart of public verifiability. Given a request { domainPrefix, domainGroup, inputs, registryVersion }, it:

  1. refuses on registry mismatch — if the supplied registryVersion ≠ the build's REGISTRY_VERSION, it returns REGISTRY_MISMATCH rather than silently answering with different physics;
  2. re-validates dimensions (checkDimensionalEngagement);
  3. re-binds constants (bindConstants);
  4. re-runs the solver (computeByDomain);
  5. rounds to the wire format — toPrecision(8) then Number() round-trip — so the output is byte-identical to the original envelope.

It uses no database, no clock, no network, and no randomness — pure float64 arithmetic. Two processes given the same request return byte-identical JSON. That determinism is specified in COMPUTE-DETERMINISM.md and pinned by a two-process bit-identity test.

Attestation — a peer re-derives and signs​

verifierNode.ts lets one node verify another's claim without any shared state. attestClaim(claim, signature, originPublicKey) runs three checks:

registry_match           — same registry version (else "unverifiable")
origin_signature         — the origin's Ed25519 signature over canonicalJson(claim) checks out
recompute_bit_identical  — re-run the physics via recompute, bit-compare value/unit/uncertainty

and returns an AttestationRecord with a verdict of agree, disagree, or unverifiable, signed by the verifier's own node key and stamped zeqond = floor(unix_ms / 777). A disagree is what sets a result's verdict to disputed.

This is explicitly not consensus. Verifiers never talk to each other, hold no shared state, and run no protocol rounds. Two honest verifiers agree because deterministic closed-form float64 physics is deterministic — not because they coordinated. requestPeerAttestations fans a signed envelope out to configured peers with a 2.5-second fail-open timeout: a slow peer contributes nothing rather than blocking the result.

Sealing — proof of elapsed Zeqonds​

proofOfElapsedZeqonds.ts makes the audit chain tamper-resistant, not merely tamper-evident, using a Wesolowski verifiable delay function. Every ~1287 Zeqonds the sealer chains a VDF over the head state:

x_k = SHA-256(y_{k-1} ‖ head_state_hash_k ‖ z_k ‖ origin_id)
y_k = x_k ^ (2^{T_k}) mod N          (T_k sequential squarings)
T_k = (z_k − z_{k-1}) × SQUARINGS_PER_ZEQOND

The modulus N is the RSA-2048 challenge number (factorisation publicly unknown). Computing the seal takes sequential work proportional to elapsed time; verifying it is O(log t) and runs offline in milliseconds via the standalone tools/verify-zeq-chain.mjs. The framework is honest about the limits: the VDF binds relative sequential time (faster hardware gets a proportional speedup), and history before the first seal is hash-chain only — tamper-evident, not tamper-resistant.

The result: portable proof​

Put the stack together and a single Zeq result carries everything a stranger needs to check it without trusting you:

  • what was computed — the operators and the printed master equation;
  • under what rules — the registry version and the kernel it was computed under;
  • with what constants — the CODATA values, named in the transcript;
  • to what precision — the ≤0.1% bound and the actual figure;
  • at what tick — the Zeqond stamp;
  • signed by whom — the node's Ed25519 public key.

Any party can re-run recompute and confirm the number bit-for-bit, check the signature against the node's public key, and — if they want — ask a different node to attest. You don't trust the node. You re-run the derivation.

The physics is the proof. The signature and the clock are what let strangers check each other.