Your hosts already know
what is wrong. Watchling asks.
A human still decides.

1. Collection ran over your jumpbox at 08:40 and read the enrolled hosts. One machine would not answer; it is named on its own row with the hop that failed, rather than silently dropped from the count.
2. web-01 reports postfix.service failed, 38 times since 03:14, with the journal lines attached verbatim. The finding is keyed on the unit's own name, so when the same condition is seen again tomorrow it is the same finding, not a new one.
3. The AI reads its prior notes on web-01 first. Two of them name the same relay. That is on the card as prior context, in the model's own words — and if the memory store had been unreachable, the card would have said so instead of implying there was no history.
4. It proposes agent.service.restart — a catalog entry, not a command line — on that one host, that one unit. Risk class elevated. The blast radius says what it touches and that it is reversible by agent.service.start. It does not touch the relay, which is a separate finding on db-02.
5. You decide. Approve, reject with a reason, or open Discuss and argue with it about the finding first. Separately, at the foot of the card, you can mark the problem a false positive, known-and-accepted, postponed, ignored or escalated — ignoring requires an explanation and is itself signed.
6. The decision lands on the chain naming you, before anything else happens. At execution the inventory and monitoring checks run again; if web-01 entered maintenance in the meantime the approval is void and it comes back to you.
7. Honestly, today: a restart is proposable and approvable, and on a deployment with no execution runner wired it refuses at execution rather than reporting a success nobody performed. An approved re-collection, by contrast, runs end to end on a real host right now — and if the unit is genuinely back, the finding closes on that evidence.

# nothing is probed until a scope is signed. the scanner verifies that
# signature against the scope's own stored contents on every run.
$ watchling scope sign --label northfield --cidr 10.20.0.0/24 \
      --signer d.okoye --id northfield
ed25519 keypair generated . authorization northfield signed . ledger genesis

$ watchling scan
targets default to the signed CIDRs . out-of-scope targets are refused
and the refusal is written down before the error surfaces

$ watchling walk <scan-id>
(a)ccept  (e)dit  (r)eject  (s)kip  (q)uit        resumable after kill -9
  NEW    10.20.0.13  app-03     not in inventory        > a
  DRIFT  10.20.0.11  web-01     primary_ip disagrees    > a
  GHOST  10.20.0.44  old-build  in inventory, not found > flagged, never deleted

$ watchling violations
every scope refusal, logged against the authorization that forbade it

Source of truth NetBox

Reads your devices as intent and diffs them against what the scan actually saw. An observed field disagreeing is a correction you walk through one at a time; an intent field disagreeing is a finding, never a silent update. Writing back is a separate step with its own gate.

Monitoring Zabbix

Reads host state and open problems, and fails closed: if Zabbix cannot answer, the state is unknown, never no problems. Where an unacknowledged event matches a finding on your host it proposes acknowledging it — that is a write, so it opens an approval.

Monitoring Nagios

Reads host and service state. Against an instance with a configuration API it also scans the config and names what has drifted — a host absent, an address wrong, a service never applied, a group membership gone. Each one is a single proposed write, approved on its own, with the paging consequence stated before you accept.

Documentation MediaWiki

Where the runbooks land. Every claim in a draft must cite evidence that resolves or it is stripped and counted; the absences are computed from the collection window, so thin history reads as thin history. Nothing publishes without a recorded human approver, and the publish is on the chain before the page is written.

Automation Ansible®

Asks your controller's own Ansible which config, playbook directory and inventory it is really using. From a finding it recommends, in plain words, the handler or task that would address it, and can surface a reviewed Galaxy playbook with a content hash to check it against. It does not write playbooks for you, and running one is escalation-class.

+ Anything else Your own

A plugin declares what it can read, what it can suggest and what it can write, and the registry refuses to register a write that is not human-approved. That is enforced where plugins are loaded, not left to the plugin author's judgement.

Start at zero. The host findings are read before any plugin is consulted and returned regardless, so with nothing connected the assessment is the host's own and it is complete. A plugin that is switched off, unconfigured or unreachable becomes a sentence naming the hop that failed — not a spinner, not a blank panel, and never a silent gap in the count. A plugin is never a requirement, and a failing plugin is a sentence, not a broken screen.

Any tool that reduces the hours needed to run infrastructure can end up cited in somebody's layoff justification, and a company that swears otherwise is lying to you. What we can do is refuse to build the features that make it easy, put those refusals in the source tree where a test enforces them, and state them publicly at version one. The full policy, including what would break it, ships in the repository as HUMANITY.md.