Evolution of mathematics.
Welcome to your deterministic
state machine.

This is the part most people get wrong about Zeq. The state machine is itself a mathematical language. The kernel runs real equations at sub-percent precision — quantum mechanics, general relativity, fluid dynamics, orbital mechanics, the lot. None of that needs an LLM. The state machine doesn't run on AI; it runs on math. AI is an optional surface laid on top of the kernel, only there to help you describe what contracts you want. The math always runs on the server, on the state machine. The LLM never touches the answer.

What we mean by "Mathematical Intelligence" (MI)

Standard AI is a language model that guesses the next token. It hallucinates because it has no ground truth — only statistical patterns over text. Mathematical Intelligence is what you get when you put a kinematic-spectrum kernel under a language model: the LLM proposes a contract in human terms ("simulate three planets in mutual orbit"), the kernel verifies the math actually works, picks the right operators, binds the real constants, runs the equations, issues a ZeqProof. Whatever the LLM produces gets checked against physics before any byte hits your screen. The result is an agent that can't lie about a number — the kernel won't let it. That's MI: AI that's been physics-grounded by a state machine.

The LLM is a translator. The kernel is the calculator. The entangled state is the receipt.

Pulse — Mathematical Intelligence on top of an LLM

Pulse mode gives you a chat surface where you describe contracts in Plain English (or any language) and the system turns your words into Zeq contracts. Two ways to power the LLM underneath:

Option A · Free limited model from us

Sign in and you get a free quota of contract translations on a model we host. It's rate-limited and capped per day, but it's free, it's instant, and it requires no setup. Good for trying the framework, prototyping a couple of contracts, getting the feel. The translations are always shown to you before they fire, and the math still runs on your kernel — the model only decides what contract to write, never what the answer is.

Option B · Bring your own API key (BYOK)

Paste an API key from a provider you already pay for — OpenAI, Anthropic, Fireworks, DeepSeek, Cerebras, Together, Groq, or any OpenAI-compatible endpoint. Your key is encrypted with HITE (AES-256-GCM under KO42) and stored against your state machine. From that point Pulse calls your account, on your tier, with your model of choice. The framework never sees the cleartext key, and you can revoke or rotate it at any tick. This unlocks longer contexts, smarter translations, vision input — whatever your provider gives you. Same kernel, same math, smarter translator.

What the LLM never does: the LLM never computes a physics value. It cannot output a number that wasn't produced by the kernel. If a contract requires R(t) at zeqond N, the kernel runs it; the LLM is told the result and weaves it into the prose. There is no path where an LLM hallucination can become an entangled state entry — the seven-step wizard rejects anything not produced by the operators.

Root — pure mathematical language, no AI in the loop

The state machine doesn't need an LLM at all. Root (the CLI) is a web terminal where you type contracts directly — zeq.compute(KO42, ψ), zeq.bind(QM5, …), zeq.pulse(), zeq.verify(proofDigest), zeq.shift(τ * 100), the entire SDK surface. The kernel ticks them through the same seven-step pipeline as the Pulse path, but with no model, no translator, no quota, no provider — just you, the math, and the entangled state. Best when you know the operator names, you're scripting reproducible work, you want zero latency, or you're paranoid about ever having an LLM in your stack.

Switch any time

The pick on this step is your first-touch preference, not a commitment. After step 7, every page on your state machine carries a Pulse at the bottom-right with a tiny ⌘ CLI toggle. Talk through a problem, drop into CLI to verify a proof digest, flip back. Contracts written one way are visible the other way. The kernel doesn't care which mouth you use — it computes the same way for both, on every Zeqond.

A password is a string a server compares to its database. A Zeq equation is a unique state-vector generated from your query, the current zeqond, the kernel's HMAC seed, and the kinematic operators selected for that exact moment in time. The server never sees the cleartext. The framework never stores the cleartext. Even an attacker who somehow obtained both your query and the precise zeqond you registered at would still need the framework's ZEQ_NODE_SECRET to reproduce the operator set you got. That is what makes an equation an identity: it's mathematically derived from your intent and the moment and the kernel — three independent factors no attacker controls all of.

Query-driven — minimum four meaningful tokens

The wizard rejects two-word inputs. Stop-words ("the", "of", "a", "and") are stripped before counting; tokens shorter than three characters are stripped. What remains must be at least four distinct meaningful words. This is non-negotiable: the equation's strength comes from the entropy of the query, and "my orbit" or "test password" cannot anchor a sovereign identity. The chip suggestions on this step are intentionally five and six tokens long — physics, materials science, quantum mechanics, oceanography phrases — so you have a starting palette that already meets the floor. Edit them, extend them, write your own. The longer and more specific your query, the more entropy and the harder to guess.

Phase-locked — bound to the exact zeqond

Every request to /api/zeq/wizard/auth-bootstrap is HMAC-bound to its zeqond. The seed is HMAC-SHA256(ZEQ_NODE_SECRET, "zeq.seed.v1|" + zeqond + "|" + queryHash), sliced to 16 bytes. The seed is fed into the operator selector, which scores all 1,500+ catalogued operators in the catalogue — token-driven semantic match plus a per-request jitter derived from the seed — and picks the top six, with one wildcard pulled from a non-matching domain to guarantee multi-domain synthesis. The same query at zeqond N and zeqond N+1 produces different operator sets and different modulated R(t) values, because the sine term in R(t) = S(t) · [1 + α · sin(2π·1.287·t)] has visibly shifted by 0.777 seconds. Two snapshots of the same query, even one beat apart, do not yield the same equation.

Zero-knowledge — the server never sees the equation

The client computes HMAC-SHA256(equation, salt) and POSTs only { equation_hash, equation_salt, display_name }. The cleartext equation never crosses the wire. The framework's database stores the HMAC and the salt — both irreversible without the equation itself. Forgetting the equation makes the account irrecoverable, by design. There is no "recover password" link, no email reset, no admin override. The framework cannot read your equation any more than someone else can.

How to save it

Three options, ranked by safety: (1) click Copy in the equation block's top-right corner and paste into a password manager (1Password, Bitwarden, etc.) — the equation is a single string of text and lives happily there. (2) click .zeq to download a PIN-encrypted recovery file (HITE encryption, AES-256-GCM with KO42) — store it on a USB, an external disk, or any secondary location. (3) screenshot or photograph the equation block — every character is captured, and an offline image is one of the most resilient backups in existence. Combine two of the three for genuine insurance. Whatever you do, do not let the equation live only in your browser's local storage; clear that storage and the equation is gone unless you have a backup.

What this gives you

One equation unlocks your machine on every device, anywhere on the network, without an account-recovery flow, without password fatigue, without revealing anything to the framework. The same equation is also the seed for the entangled state that records your contracts, so signing in and authenticating a future computation are the same operation under the hood. The framework's other apps — Vault, Mail, Message, HITE Encryption, ZSP Security — accept the same identity. One equation, every surface.

Your Zeq machine is a self-contained computational substrate. It has its own audit entangled state, its own embedded api-core, its own state observer, and its own clock — synced to the same 1.287 Hz pulse as every other machine on the network. The Zeq ID minted from your equation in step 3 is permanent: it cannot be reassigned, cannot be silently changed, cannot be impersonated. Whatever you build on this machine is hash-linked to that ID forever.

Tamper-evident entangled state — proof, not promises

Every contract that fires on your state machine writes a hash-linked entry to the entangled state. Each entry references the previous entry's hash, so any retroactive edit to history would invalidate every subsequent entry — a Merkle-style integrity guarantee on your machine's own entangled state, not a global ledger. Each contract carries a ZeqProof: an HMAC-SHA256 over the operator IDs picked, the modulated state R(t) at firing, the zeqond, and the queryHash. Anyone in the world with the proof digest can later verify what happened on what tick, in what state, with what inputs — without trusting you, without trusting the framework, and without re-running the computation. The entangled state is the receipt.

Fault-isolated — your state machine doesn't depend on ours

Each Zeq state machine runs on its own embedded api-core and its own clock. If a peer state machine crashes, yours never feels it. If the framework's mesh fabric (the consensus layer that coordinates 10 origins) degrades, your state machine keeps ticking on its own pulse until quorum returns; transitions queue locally and replay onto the mesh on reconnect. Resource limits and crash-loop protection are enforced per-state-machine: a runaway contract on one tenant cannot starve another. The fault model assumes adversarial neighbours and degraded networks as the steady state — not the exception.

Five surfaces other people reach you through

Messaging — end-to-end-encrypted address inside the framework, drop-in for email, no plaintext on any server: <zid>@zeq.dev. Public site — folder-portable page at /s/<zid>/ that anyone with the URL can reach. State observer — your entangled state rendered live at /state/?slug=<zid>, filter pills for compute / agent / contract / audit-source / proof events. API — Authorization: Bearer zsm_… for admin scope, zeq_ak_… for site publish, all keys revocable per-scope. Audit entangled state — anyone with a proof digest calls /api/zeq/verify and the entangled state proves the entire path from genesis to that point. Hash-linked under origin: zeq.dev:<zid>.

Folder-portable — your state machine isn't trapped here

The state-machine folder under /s/<zid>/ contains everything required to boot the same state machine on a different framework instance: the entangled state, the contracts, the cached operator catalogue, the public-site assets. Copy it to another VPS, point a Zeq-compatible runtime at it, and the same state machine resumes ticking. There is no "you can only run on our cloud" lock-in; the framework is the protocol, not the host.

Other apps your equation already unlocks

The Apps menu at the top of every page lists every Zeq application — Vault, Mail, Message, Zeq MI, HITE Encryption, ZSP Security, HZC Compress, Globe, Audit Daemon, Skills, Physics Wizard, Wallet — and each one is a state machine of its own. The equation that minted this machine signs you into all of them. You don't need to set them up now; they're there whenever you want them.

Most things in the world that matter — orbits, prices, populations, proteins, molecules, magnetic fields, conversations grounded in fact — obey at least one mathematical law. A Zeq machine is a runtime where those laws are first-class primitives. You don't have to translate "what should happen" into "what to compute"; you describe the regime (orbital mechanics, quantum mechanics, materials science, classical mechanics, oceanography, genomics) and the kernel selects the operators, binds the constants, and runs the math at sub-percent precision. Below: six families of applications people are already building, and one open invitation.

Physics — the canonical home of the kinematic spectrum

Three planets in mutual gravitational influence — the three-body problem rendering live on the homepage hero — is one example. Schrödinger wells (1-D, 2-D, hydrogen-atom-style), gravitational-wave inspirals, fluid flow under Navier-Stokes, lattice dynamics with phonon-magnon coupling, plasma cyclotron resonance, Casimir vacuum pressure between parallel plates, Bose-Einstein condensate vortex lattices — every one of those is a contract you can write with one line of intent. The kernel pulls the operators from the kinematic spectrum (QM1-17 quantum mechanics, NM18-30 classical, GR31-41 general relativity, plus 1,500+ more across the catalogue), binds CODATA 2018 constants, and computes to ≤ 0.1%. No hand-tuned approximation. No blunt-force numeric drift. Just the equation, executed.

Markets & finance — physics-grade volatility, microstructure, and synchronised exchanges

Markets are a stochastic system with hard mathematical laws underneath. A Zeq machine can run a live BTC chart with a Zeq operator on the volatility term, model order-book microstructure with quantum statistics (Fermi-Dirac for fee-tier asymmetry, Bose-Einstein for liquidity clustering), schedule a contract to settle at tick N when a price-state condition becomes true, or run a private exchange that ticks in perfect lock-step with every other Zeq machine on the network because they all share the 1.287 Hz pulse. You don't need a centralised matching engine; the entangled state is the matching engine.

Life sciences — genome decoders, protein folds, chemistry experiments

Anything with a kinetic spectrum belongs here. DNA helix decoding, protein folding under specific solvents, ligand-receptor binding kinetics, drug interaction simulators where the timing matters more than the average dose, epidemiology models that respect tick-by-tick state transitions, even synthetic biology workflows. The framework's kinematic operators include quantum-chemistry primitives (electron density, eigenvalue solvers, lattice diffusion) so the math you'd otherwise spread across Mathematica, Octave, and a dozen R packages collapses into one machine.

Contracts — schedule state to be true at a future tick

This is where the state-machine model is most obviously different from a normal server. You write a contract that says "at zeqond 42,000, the lending balance should be X"; the kernel arranges itself to make it true on that exact pulse. Lending, voting, vesting, escrow, conditional release, dead-man's-switch — all expressible as state-at-tick declarations, none requiring a centralised operator. Your machine is your entangled state. The framework provides the clock and the verification machinery; you provide the rules.

Conversation — agents that pass the seven-step wizard before they speak

A Zeq agent is a chat surface backed by the kernel. Every query goes through the seven-step wizard first — operators picked, KO42 enforced, constants bound, precision verified, ZeqProof issued — and only then does the LLM compose a natural-language response grounded in those numbers. The result is an agent that can't say "the Earth is 4 million years old" because the math wouldn't let it. The Pulse on every page works the same way; it's not a wrapper around ChatGPT, it's a wrapper around your entangled state, and the LLM runs after the math, not before.

Anything else you describe

If you can describe it in plain language, the Pulse can write the contracts. If you'd rather write the contracts yourself, the CLI has every operator at your fingertips. The kernel ticks them. The entangled state proves they fired. Your machine morphs — same Zeq ID, same address, same proof history, different behaviour from one tick to the next. The framework's app catalogue (Vault, Mail, Message, HITE, ZSP, Globe, Physics Wizard, Skills, Compress, Audit Daemon) are themselves Zeq machines built this way; nothing is hand-coded outside the model. They're proof the surface is wide.

Anatomy of a great prompt — the four-part recipe

Your prompt is the contract template the kernel will spin into operators. The Pulse handles vague language, but the more of these four parts you include, the cleaner the spin-up:

1 · WHAT — the noun. "A real-time physics simulation", "a market microstructure dashboard", "an interactive lesson", "a contract that fires at zeqond N". One sentence. The kernel uses this to pick the application skeleton.

2 · INPUTS — what the user (or another machine) can change. "with mass and speed sliders", "with a potential function the user drags", "with three text fields for ticker, time-frame, threshold", "with a microphone capturing pulse rate". The kernel maps each input to a typed channel on your entangled state so changes are auditable.

3 · OUTPUTS — what they see, hear, or get. "render the orbits in 3D", "plot the eigenstate alongside the potential", "show the price + a ZeqProof of every tick", "return a number plus a confidence interval". The kernel binds these to view components or API endpoints.

4 · REGIME (optional) — a hint at which physics or math family to lean on. "using orbital mechanics", "in the quantum regime", "with Fermi-Dirac statistics on the order book", "under Navier-Stokes for the fluid". If you skip this, the kernel infers from words you used in WHAT and INPUTS.

Worked example. A weak prompt: "a physics thing". A strong prompt: "a 3D simulation of three planets in mutual gravitational orbit, with sliders for each planet's mass and initial speed, rendered in real time, using orbital mechanics — show the trail of each planet for the last 100 ticks and a counter of how many ticks have elapsed." Same idea, but the strong version gives the kernel everything it needs to pick KO42 + GR31 + the orbit operators in one shot.

Start small, iterate forever — your machine is a living thing

This is the part that surprises people. Building an application on Zeq is not a one-and-done. You don't ship a finished product on tick zero. You ship a small, working version of the idea, then you keep improving it on the same machine, at the same address, with the same Zeq ID — every change is just another contract on the entangled state.

After step 7, every page on your machine carries the Pulse. From there you can say things like "add a slider for orbital eccentricity", "replace the physics with quantum tunnelling", "add a Spanish translation", "add a payment wall using my Wallet", "hook this into my MQTT sensor feed", "make the colors warmer". Each instruction becomes a new contract, fires on the next pulse, the entangled state records what changed, and the page updates without a redeploy. Your machine is a Ship-of-Theseus that proves every plank.

Practical consequence: write a small first prompt. Get something working in step 6. Then iterate from the Pulse, one feature at a time. Don't try to ship a finished product on the first pulse — the framework rewards small contracts that compose, not monolithic ones.

Examples — pick one, edit it, or write your own

Physics: "a physics engine for orbital mechanics with mass and speed sliders" · "interactive 1-D Schrödinger well with the potential as a slider" · "a Three.js scene of three planets orbiting" · "double pendulum with phase-space plot side-by-side" · "Casimir vacuum pressure between parallel plates, distance slider".

Quantum: "hydrogen wavefunction explorer with n/l/m sliders" · "quantum tunnelling barrier with width and height sliders" · "spin-1/2 Bloch sphere with magnetic-field controls" · "Bell-state entanglement visualizer".

Markets & finance: "live BTC chart with my Zeq operator on the volatility" · "options pricer with implied-vol surface" · "order-book heatmap with depth controls" · "Black-Scholes Greeks panel with time-decay slider".

Life sciences: "DNA helix decoder with codon highlighter" · "protein folding under different solvents" · "drug interaction simulator for two-dose regimes" · "epidemiology SIR model with vaccination toggle".

Aerospace, energy, environment: "Hohmann transfer planner Earth-to-Mars" · "satellite orbit decay simulator" · "solar panel output curve under variable irradiance" · "ocean carbon flux model with temperature slider".

AI grounded in the kernel: "math-grounded chat agent that can't lie about a number" · "agent that plans through the seven-step wizard before each move" · "RAG pipeline backed by my entangled state not a vector DB".

Education & articles: "an article about KO42 with equations typeset in MathJax" · "interactive Schrödinger lesson for high schoolers" · "Newton's laws sandbox with collision controls".

Pick any of those, edit it to fit you, or write your own. Tap Synthesize and watch the kernel pick the operators live.

The seven-step wizard is the kernel's invariant pipeline. Every contract — whether it came from the Pulse's natural-language translation, the CLI, the SDK, or an external API call — passes through these seven gates before a single byte of result is written to your entangled state. The same protocol that minted your equation in step 3 runs every tick, forever, on every machine. There is no fast path, no admin override, no "just run it raw." This is what we mean by physical compiler — code that breaks the rules won't compile (dimensions, bounds, conservation checks), and code that passes is signed, dated, and verifiable forever.

Step 1 — SELECT (operators chosen from the kinematic spectrum)

The kernel reads your contract's intent and selects operators from the 1,500+ catalogue. Selection isn't keyword matching; it's a scoring function that weighs the query tokens against operator names, equations, descriptions, and IDs, then applies a per-request HMAC-derived jitter so two structurally identical contracts at different zeqonds pick different operators. KO42 — the framework's bounded modulation — is always included; it stamps the tick phase and carries the numeric-accuracy bound every result reports against. A wildcard pick from outside the matched domain guarantees multi-domain synthesis where the math allows it, so a contract about orbital mechanics can pull in a relevant operator from materials science if it improves the model.

Step 2 — BIND (real constants, not stand-ins)

The selected operators get their constants bound from NIST CODATA 2018: c (speed of light), h (Planck's constant), G (gravitational constant), k_B (Boltzmann), e (elementary charge), ε₀ (vacuum permittivity), and the rest. These are the canonical reference values used by every physics laboratory on Earth. The framework's kernel resolves them once at boot and pins them; nothing in your contract entangled state can drift them.

Step 3 — VALIDATE (dimensional analysis + domain constraints)

Inputs pass through a sanity gate. Mass cannot be negative. Velocity cannot exceed c. Temperature cannot be below absolute zero. Radius must be positive. Non-finite values are replaced with sensible defaults and the warning is recorded in the audit log. Dimensional analysis ensures you're not adding metres to seconds or multiplying kilograms by joules. Anything that breaks the contract of physical reality gets rejected before it runs — which is the point.

Step 4 — COMPUTE (domain-specific solver runs the math)

The domain-matched solver runs the actual computation. This is where the operator equations are evaluated against the validated inputs: the wave equation, the geodesic equation, Maxwell's equations, the Schwarzschild metric, the Friedmann equation — whichever apply. No approximation unless your contract explicitly requested a degraded mode (the VX fallback for paid users over quota). The output is a numeric value plus an uncertainty estimate, plus the equation in symbolic form for downstream verification.

Step 5 — VERIFY (precision against KO42's ≤ 0.1% bound)

The computed value is checked against the KO42 ground-state reference: R(t) = S(t) · [1 + α · sin(2π · 1.287 · t)], where α ≈ 1.29 × 10⁻³. The deviation between your result and the modulated reference must fall under 0.1%. Pass and the result moves on. Fail and the verification is flagged in the protocol_steps array, but the result still proceeds — the entangled state records both the failure and the value, so a future audit can see exactly which contracts triggered precision warnings.

Step 6 — PULSE (synchronise to the HulyaPulse)

The result is modulated by the HulyaPulse at the exact zeqond it fires. This is the framework's universal synchronisation step: the same R(t) modulation applied to every contract on every machine, at the same beat. Two machines computing the same query at the same zeqond get the same modulated value. The phase is computed as φ = (t mod τ) / τ where τ = 0.777 s; the sine term locks every machine's output to a shared waveform. This is what makes inter-machine coordination work without explicit clock-sync messages — the universe is the clock.

Step 7 — RETURN (ZeqProof issued, entangled state advanced)

The kernel emits a ZeqProof: an HMAC-SHA256 over the operator IDs, the modulated R(t), the zeqond, the queryHash, and the node's secret. The proof is hash-linked to the previous entangled state entry under your machine's KO42 root. The application — whatever you described in step 5 — renders, grounded in those numbers. Anyone with the proof digest can later call /api/zeq/verify and the entangled state replays the entire path, proving the result was produced exactly this way at exactly this tick. The machine ticks on; the next contract begins step 1.

Why this is the security model, not just the compute model

Because the seven steps are the only path to an entangled state entry, the entangled state is automatically a tamper-evident log of every computation that has ever passed the precision contract. There's no separate audit subsystem. There's no "and then we also write to a log somewhere"; the protocol is the log. Your contracts and your security guarantees are the same primitive expressed two ways.

When your machine is live, three surfaces carry it into the world. They share nothing with the framework's hosting layer except the protocol; the keys, the entangled state, and the kernel are yours alone. Visitors see what the kernel exposes — the application your contracts produce, the entangled state's verifiable history, and the live tick — but never your equation, your tokens, or your private state.

/s/<your-id>/ — the public site

This is the page anyone with the URL can reach. Whatever your latest contracts produce — a physics simulation, a crypto chart, an article, a chemistry lab, a contract dashboard — renders here, refreshed in real time at the 1.287 Hz pulse. The folder under /s/ is portable: copy it to another framework instance and the same machine boots there with the same identity. The site is rate-limited per-machine, fault-isolated from peers, and protected by the framework's bot-defence layer (the same one that blocks scraper farms but lets curl, the SDK, and legitimate agents through). You can flip it private at any tick — only you, signed in, see the page; the URL returns 402 to everyone else.

/state/?slug=<your-id> — the live observer

The state observer is a public, read-only window onto your machine's entangled state. Every contract that fires — its operators, its inputs, its modulated R(t), its zeqond, its ZeqProof, the operator-coverage breakdown, the precision deviation — appears here in real time. Filter pills at the top let visitors slice by event type: compute, agent spawn, agent compute, contract, audit-source, ZSP transitions. The narrator daemon adds plain-English summaries next to each row ("at zeqond 218,194,521 your machine ran a quantum-mechanics SELECT, picked QM5 + KO42 + ON0, produced 1.45e-19 J with 0.04% deviation"). Read-only by default; if you want to expose admin actions, you mint a scoped key and share that separately.

The audit entangled state — verifiable forever

Every entangled state entry references the previous entry's hash, which references the one before, all the way back to genesis. Any retroactive edit invalidates everything that came after, and the framework's mesh would refuse to accept the rewritten entangled state on next sync. Anyone with a ZeqProof digest can call POST /api/zeq/verify with the digest and the framework replays the operator selection, the constant binding, the validation, the compute, the verify, and the pulse — proving the result was produced exactly this way, at exactly this tick, with exactly these inputs, under your KO42 root. The entangled state is the receipt for your machine's entire life.

The Pulse — your machine's permanent chat surface

After step 7, every page on your machine carries a small Pulse at the bottom-right. Tap it and the on-device Pulse takes a new instruction in plain language: "rebuild this as a chemistry experiment", "turn this into my crypto dashboard with my Zeq operator on the volatility", "show the entangled state digest for the last twenty contracts", "make the simulation run twice as fast". The Pulse turns your words into contracts, the kernel ticks them on the next pulse, and the page updates. You're never locked in. Same address, same ID, same entangled state — different machine behaviour from one tick to the next.

Public, private, somewhere in between

The toggle on this step controls visibility. Public means anyone with the URL can reach the site and the observer. Private means only the equation that minted the machine can sign in to see it. You can also publish via scoped keys: a Bearer zsm_… for admin scope, a zeq_ak_… for site-publish scope, both revocable per-key. Mix-and-match — public site + private observer, public observer + admin-only contracts, totally air-gapped — the policy is per-surface, not all-or-nothing.

What "live" actually means

"Live" means your machine is on the framework's mesh, ticking at 1.287 Hz, advancing its entangled state on every contract, reachable at /s/<your-id>/. It does not require attention from you to stay alive — the kernel is always running. It does not bill you to stay alive — the basic tier is free and unmetered for sovereign personal use. Walk away and the machine ticks on. Come back tomorrow, sign in with your equation, drop a new contract; it picks up exactly where it was at the zeqond you left.