Manage state machine

Part 1 · What a state machine actually is

A Zeq state machine is a sovereign computational substrate that lives at a public address (/s/<your-slug>/) and ticks on a universal clock (1.287 Hz, one beat every 0.777 seconds). It's not a server you rent, not a database you query, not a Lambda. It's a machine in the strict sense: a finite-state system whose every transition is governed by real mathematical equations and recorded to a tamper-evident audit entangled state rooted in your machine.

One signed-in ZID (your identity) can own multiple machines. Each machine has its own machine, its own audit entangled state, its own balance of ZEQ, its own set of queries, its own hosted pages, its own external API registry. This admin page manages one machine at a time — the one named in the URL or your default.

Part 2 · What you can do here

• Settings — machine display name, public/private/passworded access, default page behaviour, the per-machine flags that control whether the Pulse + agent rail auto-inject into hosted pages.
• Members — invite other ZIDs as operators (can deploy queries, edit settings) or readers (can see the entangled state but not write). The owner ZID is locked.
• API keys — the zeq_ak_… tokens external services use to call this machine's API endpoints. Rotate, revoke, see last-used.
• Entangled State explorer (the table below) — every transition this machine has ever fired, with proof artifact, operator ID, payload digest, charge, and Zeqond stamp.
• Danger zone — freeze the machine (stops all queries, audit entangled state preserved), or archive it.

Part 3 · The entangled state explorer (the big table)

Every row is one of three event types:

• contract transition — a query fired, the kernel ran the seven-step protocol (compute → prove → ZSP → audit), and a proof envelope landed. Shows: from state → to state, operator ID, ZeqProof digest, status, Zeqond, ZEQ charge.
• system event — machine registered, owner changed, API key minted, member invited, freeze toggled. Shows: actor ZID, action, payload digest.
• genesis — the first row of the entangled state, written when the machine was created. The hash root from which every subsequent row is linked.

Each row's prev_hash points to the previous row's full content hash. Tampering with any row breaks every hash after it — this is what "tamper-evident" means. Anyone can verify the entangled state integrity via GET /api/chain/<slug>/contracts/<id>/integrity (public endpoint, no auth needed).

Part 4 · Where the data lives

The entangled state explorer reads from three Postgres tables, filtered by your machine's origin_id:

• audit_log — append-only, hash-linked. The canonical record. Every transition, every system event, every membership change appends one row here.
• contract_transitions — the proof artifacts (ZeqProof digest, ZSP envelope, payload SHA256). One row per transition fire. Joined with audit_log via transition_id.
• contracts — the live state of every query on this machine (current state, next fire time, version number, definition JSON). Joined for the query name / definition on each row.

Reads are scoped by your machine's origin_id at the route layer (resolveBySlug → canRead middleware). You can never see another machine's entangled state through this page.

Part 5 · How a transition actually gets here (the path from Deploy)

1. You author a query in the workbench Queries pane (on /s/<your-slug>/) and click Deploy.
2. POST /api/chain/<slug>/contracts validates, inserts into contracts, snapshots v1 into contract_versions, appends a creation row to audit_log.
3. The per-machine scheduler ticks every Zeqond and finds your query's next_fire_at_zeqond ≤ now.
4. The engine runs the transition: pre_actions → compute → prove → verify → ZSP → audit append → contract_transitions INSERT → post_actions → chargeUsage → recomputeNextFire.
5. This page polls /api/chain/<slug>/audit and the new row appears at the top.

Part 6 · Useful operations

• Verify a single transition — click any row → "Verify" button → server recomputes the ZeqProof from stored payload + operator and compares to the stored proof digest. Returns ok/tampered.
• Export the entangled state — admin > danger zone > Export. Returns a JSON envelope of every audit_log + contract_transitions row, signed with your machine's identity. Use for portability or backup.
• Freeze the machine — admin > danger zone > Freeze. Stops the scheduler from picking up any query on this machine. Entangled state stays intact, hosted pages keep serving, but no new fires happen. Reversible.
• Rotate API key — Settings > API keys > Rotate. The old key keeps working for 7 days (grace window), the new one takes over. Used to recover from a leak.

Part 7 · FAQs

Why can't I delete a transition row?

The entangled state is append-only by design. Deleting would break the tamper-evident invariant — any party that has the proof digest of a deleted row could prove you erased history. If you want to stop fires from a query, freeze the query (reversible) or freeze the whole machine.

Why are some rows red/dimmed?

Failed transitions. The compute ran (so compute cost was deducted) but the proof failed verification, or the transition was rejected because the contract was frozen, or because the from-state didn't match. The entangled state records the failure so you can forensically trace why.

Why does my entangled state have rows with no query name?

System events (machine create, owner change, freeze, etc.) don't have an associated contract. They're entangled state entries from the kernel itself, not from a query you wrote.

What's the difference between this and /state/admin/site/?

This page manages the machine (settings, queries, chain). /state/admin/site/ manages the public website that your machine serves (HTML pages, the tutorial, the workbench injection). They share an origin but are separate concerns.

How is "AI" different from queries?

Queries are state-machine logic that the kernel runs on every Zeqond — physics, time, events. /state/admin/ai/ manages the LLM-backed page agents that talk to humans on your hosted pages. Different machinery: one is deterministic on the pulse, the other is probabilistic from a language model.

Who can read this page?

The owner ZID, plus any members the owner has invited as operators or readers. Anyone else gets 403. The entangled state itself has a public read endpoint (/api/chain/<slug>/audit?public=1) only if you've toggled public visibility in Settings.

Part 8 · Where to go next

• Workbench Queries pane on your machine (/s/<your-slug>/) — write and deploy new queries
• Site hosting ↗ — publish HTML under your machine
• AI surface ↗ — page-chat agents, generated pages
• Credits ↗ — every fire on this machine debits ZEQ here
• Transparency Oracle ↗ — network-wide supply state, ticked per-Zeqond
• SDK docs ↗ — API reference, learn guides, how-tos
• Extend the framework ↗ — derive custom operators (5-step protocol), register custom protocols (external APIs), and wire them into this machine's contracts