◎ Guide
◆ Build
▶ Run
⇄ Connect (ZeqSSH)
⌘ SDK
What is a ZeqReactor?
A reactor is a simulation that never stops correcting itself. You give it a starting state and a rule for how the next step depends on the last one plus whatever your sensors, market, or software is reporting right now. It runs one physics/math solver each step, and — this is the point — each step's result is a sealed, verifiable envelope, hash-linked to the one before it. So you don't just get a simulation; you get a tamper-evident record of a live, data-driven process you can replay and prove.
xn+1 = seal( Solver( T(xn, un) ) )
xn = the sealed state now · un = your live environment reading · T = the rule mapping them into the next step's inputs · seal = compute it, check it to ≤0.1%, stamp it.
What you'd use it for
Digital twin
Mirror a real machine, patient, or reactor: feed it live measurements, keep a bounded, sealed model of state advancing in lockstep.
Control loop / MPC
Each step reads the plant, computes the next actuation, and seals it — an audit trail of every control decision, reality-gated so a bad state halts.
Sensor fusion / tracking
A Kalman reactor fed noisy GPS/radar; the estimate improves as noise carries in, every update proven.
Adaptive simulation
A tumour front, an epidemic edge, a climate cell that keeps evolving from its own last field as parameters change with the environment.
How it works — five steps
Build a contract. Pick a solver (any of the 26), give it starting inputs, and write the transition: which next-inputs come from
env.* (your data), which carry from output.* (the last result), which are fixed. Do it in the Build tab.It seals step 0. The reactor runs the solver on your initial inputs and seals the first state — a real CKO envelope on your ZID.
You push the environment. Send a reading (
step with an env, or observe if the contract is on-observe). The transition maps it into the next inputs.It computes + seals the next state, hash-linked to the previous (
prev_state_proof). If it fails its ≤0.1% reality check it seals observable-differential and your onUnverified guard decides — halt (safe) or continue. A blown-up state can never seed the next.Consume the states — watch them live in the Run tab, or hand them to other software over a ZeqSSH encrypted line (Connect tab) with no API key.
Connect it to any data
In the Run tab, the environment for each step can come from:
→ Manual JSON — type a reading (great for testing a contract).
→ Poll a URL — any JSON endpoint (a sensor gateway, a weather/price API, your own server); the app fetches it each step and feeds it in. Map fields with a dot-path if the shape differs.
→ Browser — device time / random / battery, a stand-in for real telemetry.
From a server or device with no CORS limit, drive it directly with the loops in the SDK tab.
→ Poll a URL — any JSON endpoint (a sensor gateway, a weather/price API, your own server); the app fetches it each step and feeds it in. Map fields with a dot-path if the shape differs.
→ Browser — device time / random / battery, a stand-in for real telemetry.
From a server or device with no CORS limit, drive it directly with the loops in the SDK tab.
Reactor vs Stream — which do I want?
ZeqReactor (here)
- State evolves: each step depends on the last + live data
- A feedback loop / digital twin
- Hash-linked chain of sealed states
ZeqStream ↗
- Broadcasts one sealed envelope, re-fired
- No feedback — same computation each fire
- A live endpoint for a fixed result
Every step is proof
Each step is a normal sealed compute in your entangled-state chain, tied to your ZID, and linked to the previous step's proof. Given the initial input, the contract, and the environment log, the whole trajectory is replayable and independently verifiable — a cryptographic record of a live, environment-driven simulation. Full reference in the SDK docs.
A reactor is a transition contract + a solver + its latest sealed state. Each step maps the previous output and the live env into the next solver's inputs, runs it, and seals it — hash-linked to the last.
raw transition JSON
Select or build a reactor, then drive it here.
Select a reactor to open its encrypted line.
The loop
xn+1 = seal( Solver( T(xn, un) ) )
xn — the sealed CKO envelope at step n (value, field, R(t), master-equation terms, functional E, spectral Ψ, receipt, proof). un — the environment reading your software pushes in. T — the transition contract: a declarative map from (output, env) to the next solver's inputs. Each step seals verified only if it passes its own ≤0.1% reality check; a blown-up state can never seed the next.
Transition contract
—
Each transition.inputs value is a literal or a dot-path over { output, env, step }. Field carry makes a stateful twin: "initialState": "output.finalDensity" (e.g. a tumour front that keeps advancing).
Drive it from your software
—
—
—