ADR-002 makes every supervision surface a client of the operation layer, and names in its own context the case the operation layer cannot show: a custodian that is down, since signatiod does not start without its custodian — that case is `signatio-boot service status`'s, outside the daemon. Measured 2026-09-26 in code/install/signatio-boot: `service status [--name <n>]` is read-only — it reports whether the signer and daemon units are loaded, has `signatio probe-custodian` ask the signer's socket for its key, has `signatio probe-authority` check that the daemon answers under that key, and shows the daemon's last refusal to start from `<data_dir>/log/daemon.log`; it exits 3 unless both attend, and it prints lines of text only. The units write their output to `<data_dir>/log/signer.log` and `<data_dir>/log/daemon.log`, the data_dir being the last argument the installed signer unit passes to `run`. desk, the supervision surface of ADR-002, shows none of it: a custodian down is invisible in the tool meant for supervising. The principal decided, 2026-09-25, that desk shows the service status and the logs, and, 2026-09-26, that the status is printed in the format each consumer asks for, the consumer deciding how to use or expose it.
WHAT THE OPERATION LAYER CANNOT SHOW, THE LAUNCHER DOES. A custodian down, a daemon that refused to start and why, are invisible to POST /v1/op, since signatiod does not start without its custodian. A supervision surface shows them by running `signatio-boot service status`, the verb that already answers it: the units loaded, the signer attending with its key, the daemon answering under that key, the daemon's last refusal to start.
THE LAUNCHER ANSWERS IN THE FORMAT ASKED. `signatio-boot service status` takes `--format text|json` — text by default, as an operator reads it, and JSON as a program reads it, the same facts in both. What a consumer does with the answer — show it, summarise it, alert on it, expose it further — is the consumer's: the launcher states the facts and names no consumer. desk asks for JSON.
A STACK WITHOUT UNITS IS PROBED BY ITS DATA_DIR. `signatio-boot service status --data-dir <dir>` probes the custodian and the daemon of the stack laid out in <dir> — signer.ncl, signatiod.ncl, log/ — as it probes an installed service's, and answers that no service is installed, with no units, and with the data_dir, the signer and the daemon it probed: a dev stack started by `just dev` is seen for what it is. When <dir> is the data_dir of an installed service of that name, the answer is that service's, units included. The facts are still the launcher's; a surface that is told a data_dir passes it on, and learns no layout.
READ-ONLY, BY VERB. A supervision surface runs `signatio-boot service status [--name <n>] [--format …] [--data-dir <dir>]` and `signatio-boot --version`, and no other verb of the launcher: never install, uninstall, restart, run, layout or handover. Installing, starting and stopping the pack stay the operator's, from their own shell.
THE LOGS THE UNITS NAME, NOTHING ELSE. A supervision surface reads `log/signer.log` and `log/daemon.log` under the data_dir the launcher's answer names — the installed signer unit's, where the units write, or the stack's it was told — and nothing else under that data_dir: not signer.ncl or signatiod.ncl, not the store, not the socket.
ADR-002 HOLDS. The authority is still reached only through the `signatio` binary; the surface opens no listener, reads no store, and can do nothing its operator could not do from their shell.
desk's sources name none of the launcher's changing verbs: install, uninstall, restart, run, layout, handover
desk's sources name nothing under the data_dir the launcher answers — an installed unit's or a stack's — but its logs: not store.redb, signer.ncl or signatiod.ncl
signatio-boot's service status takes --format text|json
signatio-boot's service status takes --data-dir <dir>
An observation listener in signatiod
Rejected: Rejected by ADR-002, and it cannot show the case at issue: a custodian down keeps signatiod from starting at all.
The surface runs `signatio probe-custodian` and `signatio probe-authority` itself
Rejected: It would repeat how signatio-boot finds each unit's data_dir, socket and pin; two copies of that knowledge drift, and the launcher is where the units are declared.
The surface reads launchd's or journald's logs
Rejected: Specific to each operating system, and wider than the two files the units write.
The launcher prints a format made for desk
Rejected: It would learn one consumer's needs; the principal decided that the launcher prints the format asked and each consumer decides how to use or expose it.
The surface shows nothing and points to the terminal
Rejected: The case worth seeing most stays invisible in the tool meant for supervising.