Nishi Family › Compare › Supervision and Service Monitoring

Nishi vs the Field

Supervision and Service Monitoring — mechanically measured, liar-killed, sovereign.

Nishi vs systemd and supervisord and Prometheus and Netdata

How this is scored. Every Nishi cell is measured: the generator reads the real organ source on disk and requires the implementing symbol to exist (no self-grading). Competitor cells record documented capability presence. Best=leads this axis, Yes=present, Part=partial, No=absent. This is capability presence, not depth or scale: the majors lead on index size and neural ranking. Nishi's genuine exceeds are the sovereignty / neutrality / determinism axes.
CapabilityNishisystemdsupervisordPrometheusNetdataNotes
Process supervision with crash-restart guardsYesBestYesNoNoLIVE on the NAS: supervise + per-service guards; a guard restart of nx_relate_daemon was captured in this session's nx_status output; systemd is the init-system bar
Never-brick deploy watchdog (health-gated promote + auto-rollback)YesNoNoNoNoDEPLOYED-GREEN proven across mgmt/edge/office arcs; the field bars supervise OR observe -- none promote with rollback (that is Argo-class territory, see /compare/deploy)
Health snapshot + service inventory APIYesYesYesPartYesmgmt_snap.json written each poll; GET /api/services returned the live 14-service inventory over MCP in this session
Deployed-capability liveness audit (BUILT is not LIVE)YesNoNoPartNoThe RACI monitor activity exists because a built reader shipped dead; this organ proves served-and-wired, not just compiled; Prometheus blackbox probing is the partial peer
Accountability-routed monitoring (RACI lineage)YesNoNoNoNoMonitoring findings resolve to the ONE accountable role; the field routes to dashboards, not owners
Live-derived maturity grading (anti-staleness by design)YesNoNoNoNoGrades re-derive from evidence files on every read -- a snapshot grade is impossible by construction; exposed live as an MCP tool
Web health dashboardNoNoPartPartBestA /health fleet UI exists in the containers arc but no serving symbol verified in THIS fleet's organs -- counted absent honestly; Netdata auto-dashboards are the bar; Prometheus needs Grafana
Time-series metrics databaseNoNoNoBestYesPrometheus TSDB is the bar; our snapshots are point-in-time, no history
Alerting rules + notification routingNoPartPartBestYesAlertmanager is the bar; our vizsla reminder engine fires medical deadlines but is NOT wired to service alerts -- the named next rung
Log aggregation + searchNoBestPartNoPartjournald is the bar; our logs are per-daemon /tmp tails read via status
Per-service resource metrics (CPU mem IO)NoPartNoYesBestNetdata per-second resource visibility is the bar; systemd cgroup accounting partial
Anomaly detection / AIOpsNoNoNoPartBestNetdata ships ML anomaly bits; nothing sovereign here yet
SLO / error-budget trackingNoNoNoPartNoPrometheus recording rules approximate it; we track gate GREEN, not error budgets
Socket / timer activationNoBestNoNoNosystemd socket activation is the bar; our daemons are always-on
Dependency-ordered startup graphNoBestPartNoNosystemd unit graphs are the bar; hostctl starts a flat ordered list
Resource-limit enforcementNoBestPartNoNosystemd cgroup limits are the bar; rule 21 is awareness, not enforcement
Multi-host federated monitoringNoNoNoBestPartPrometheus federation is the bar; laptop+NAS+workers exist but each is watched alone
U1 visual design of the monitoring surfaceNoNoNoPartBestU-axes vs the NAMED product Netdata v2.10.3 dashboard (banked 2026-07-10); we ship no monitoring UI to grade
U2 interaction quality (drill-down, filtering, latency)NoNoNoPartBestNetdata per-second interactive charts are the bar; nothing of ours to grade
U3 information design (what to look at first)NoNoNoPartBestNetdata auto-organizes by host and service; our status output is a raw console dump
U4 polish and cohesionNoNoNoPartBestHonest zero until a sovereign monitoring surface exists
Promotion and monitoring as ONE never-brick circuitBestNoNoNoNoDeploy gates on health, watchdog auto-rolls-back, guards respawn, liveness audits -- one auditable loop in one substrate; the field splits this across four tools and none rolls back
Capability-token remote ops with fixed-arg pinningBestNoNoNoNoRemote status/health run pinned allowlisted subs -- a hostile argv is IGNORED (proven 2026-07-08); no ambient authority anywhere; the field uses SSH keys and bearer tokens with full shell reach
coverage 347/1000EXCEEDS 2PRESENT 6ABSENT 15
Honest verdict. The Nishi supervisor is a REAL running supervision loop with a property none of the field bars carry: promotion and monitoring are ONE never-brick circuit -- deploys are health-gated with automatic rollback, crash guards respawn daemons live on the NAS (a guard restart was captured in this very session's status output), and the liveness auditor exists precisely because BUILT-but-not-LIVE once shipped a dead end. Remote operations ride capability tokens with fixed-arg pinning, not ambient authority. Against the field it is honestly thin on observability depth: no time-series database, no alerting rules, no log aggregation, no anomaly detection, no SLO tracking, no resource-limit enforcement, no federation -- Prometheus and Netdata own those axes. The climb: a sovereign metrics store feeding the /health surface, alert routing through the vizsla reminder engine that already fires deadlines, then per-service resource metering.

Generated by nx_swcompare_matrix (sovereign NishiLang organ) from knowledge/compare/supervisor.matrix — every Nishi cell verified against real organ source on disk. Zero JS, zero trackers.