Guardian

Making TSUNAGI operable by normal humans

A node you can't safely operate is a node you can't trust. Guardian wraps the exact procedures that shipped every canonical block — deploy, verify, roll back, recover — into one console, with verification built in and foot-guns removed.

Direction · as of 2026-10-05

Designed for autonomous operation

TSUNAGI is being developed toward safe self-recovery, automated update qualification and rollback with minimal operator intervention. Guardian is the foundation. What is demonstrated and what is still in development are kept apart:

Demonstrated — crash detection, evidence capture before restart, and bounded automatic restart. In a controlled rehearsal on the live Preview producer (June 2026), a hard kill (kill -9) was recovered in 3.8 s with no human action, and the restarted node was forge-armed and clean.
In development — recovery when the process stays alive but stalls (one such Preview incident was recovered by an operator-authorized restart, not autonomously), automated update qualification, and rollback without an operator at the keyboard.
Unchanged by design — this website can read the node and can never control it.

Design rule

Control stays on the box

One deliberate decision shapes everything here: this website can read the node; it can never control it. The dashboard consumes a published status file. All state-changing operations — rollback, restart, upgrade — happen through guardianctl on the relay itself, over SSH, with an explicit typed confirmation. A block producer holds keys; a "one-click rollback" button on a public web page would be a hole, not a feature. One click on the machine, zero clicks on the internet.

The console

guardianctl

Rollback center

versions · rollback

Shows the current binary (sha-verified against the live process), the full rollback chain, and snapshots. Rollback is one command: auto-snapshot, stop, swap, sha-verify, restart, verify again. Environment, keys and opcert state are never touched.

Health center

status · health

Pass/warn checks against the proven-good baseline: process up, zero spawn failures, zero disconnect churn, live sigma source, parked serve connection present, status endpoint answering.

Diagnostics

diagnose

Scans the recent log for the signature of every known incident in the KINTSUGI catalogue (INC-001…INC-013). A failure the node has seen before is identified in seconds, with its incident file — nobody debugs the same bug twice.

Upgrade center

upgrade

Takes a release tarball and its expected SHA-256. Extracts, verifies, snapshots the current binary, swaps, restarts, verifies the running process. A sha mismatch refuses at every stage — an unverified binary cannot reach the forge path.

Recovery center

restart · snapshot · rollback

Restart (same binary), snapshot (preserve current), rollback (any chain entry). State rebuild and snapshot-restore follow the documented recovery procedure shipped with the node.

Truth feed

gen-status-json

The read-only generator behind the live dashboard: process facts from /proc, chain facts from the node's own status endpoint, health counters from the forge log. If it can't read a value, the dashboard says "unavailable".

What it looks like

$ guardianctl health
== TSUNAGI Guardian — health ==
OK  process running (pid 2588672)
OK  spawn_fail = 0
OK  disconnect churn = 0
OK  intersect not_found = 0
OK  sigma source = stake_source (live)
OK  parked serve connection active
OK  node status endpoint responding

$ guardianctl diagnose
== TSUNAGI Guardian — diagnose (KINTSUGI signature scan) ==
clean — no known incident signature in recent log

Install center

Installing TSUNAGI

Honest status: the TSUNAGI Preview producer runs as a single operator-deployed installation, deployed from sha-verified bundles using the same procedure guardianctl upgrade automates. Separately, a portable Preview follower build is published with its checksum on the Download page; it is not the producer build. A one-command install (beginner mode: guided; advanced mode: verified tarball + checksums) is planned — it will be announced here, and not before it's real.

Beginner mode (planned) — one command, guided setup, Guardian installed alongside the node from day one.
Advanced mode (planned) — verified tarball, published checksums, explicit control of every path.
Today — the deploy runbook and recovery procedure are documented and battle-tested; every canonical block was produced by an installation managed this way.