User guide verification

What each check establishes

Check	Evidence to keep	What it establishes
--version and --about	Version and attribution output	The installed command runs the expected payload.
--verify	All scenarios pass; command exits successfully	Synthetic inputs exercise the detector logic for Planes A, B, and C, including benign cases. It does not create live ledger findings.
--self-test	Per-plane lines, host-plane status, process and socket counts	The current execution context can reach the platform acquisition mechanisms. Read every plane line, even when the final line says PASS.
A bounded live run	Startup banner and verbose poll lines	The sensor actually collects processes, connections and host events on this endpoint.
A controlled AI session	Time, host, process, provider and matching ledger entry	The real workload reached a recorded finding.
Dashboard and destination search	The matching host, time and event	The record reached each configured presentation or central collection path.

Exercise the three planes

Use an endpoint you administer and an approved test account. Before starting, record the host name, time, AI application, provider and expected activity. Use test prompts and disposable files. Keep credentials out of commands and transcripts.

1. Plane A - process and compute. During the bounded run below, open your approved local model runtime, if one is available, and run an ordinary inference request. Confirm that the live sample has processes and that verbose polls continue. Look for the runtime in the self-test output and for any corresponding finding. A busy process alone is not a promised detection; --verify supplies the repeatable logic check when no model runtime is installed.
2. Plane B - network. Use an approved AI client to make a real request to its provider while the sensor is running. Record which application and provider you used. Match the process, provider or endpoint, and time in the ledger. A generic website fetch is not an equivalent test of AI-client attribution.
3. Plane C - host activity. While the bounded sensor runs, open another terminal and launch a harmless child process with the command shown below. Inspect the host-plane startup line and verbose esf= event counts. The name esf is used in the CLI and telemetry across all three platforms. Nonzero counts demonstrate host-event intake; they do not certify every subscription or tactic. Keep any DEGRADED or UNAVAILABLE result as an unresolved acceptance item.

A harmless shell command is not expected to become an agent-tactic finding. The synthetic matrix tests the detection decisions without creating accounts, changing persistence, or touching credentials. To validate a real host-plane alert, use your organization's approved lab exercise and correlate its resulting shadowclaw.agent.activity and finding events. Do not declare that alert path verified solely because the service is running.

Acceptance record

Record a separate outcome for each plane: verified, degraded, failed, or not exercised. Retain the version, host, execution identity, test time window, matrix result, per-plane status, ledger verification result, and matching destination event. An empty ledger on an idle host is possible; it is not evidence of full coverage. If a declared workload produces no expected finding, keep that test unresolved and use the troubleshooting section rather than changing detection settings to manufacture a pass.