Who gets told when work needs attention?

An inspectable record is useful, but it is not a notification. Someone still needs a supported way to receive and act on an alert.

What exists today

Classic NQ selects new, escalated and recurring findings above a configured severity threshold, groups them, and sends them through configured webhook, Slack or Discord channels. Its durable finding-level cooldown suppresses repeated notifications. A recorded notification cycle does not prove delivery: eligibility is consumed even when the send fails. See the deprecated source for historical behavior, not a new installation recommendation.

Constellation NQ can retain an exact attention intent, replay the matching Nightshift decision where applicable, and make one bounded Slack or Discord webhook request. It records a factual delivery state; it does not establish that a person saw the message. An installed route and its current recipients must be checked separately. PagerDuty is not a supported profile.

Keep four responsibilities separate

None of these records grants execution permission. A sent message, acknowledged alert or resolved incident does not prove that the underlying work succeeded. AG authorization, Docket custody and outcome reconciliation remain separate.

For a matching predicate workflow, Nightshift implements an operator-policy attention decision and exact replay. NQ uses this bounded replay before it retains delivery custody or contacts a configured endpoint. Replay is an attention-side consistency check: it does not refresh evidence, send a message by itself, or establish that the underlying work succeeded.

Deliver to a local operator inbox

Use NQ d0086b8a8df81741c661070c92a86a79bdb73362 and the exact companion pins in the worked example. An explicit local_file route selects an existing, operator-owned, mode-0711 inbox directory below a protected parent. A prepared intent must name local-inbox:ROUTE exactly. Run nq --config ./nq.toml notification deliver-local --intent ./intent.json --route ROUTE, then inspect its notification ID. The command retains one bounded mode-0600 message, not a private evidence bundle. Unknown writes are not automatically repeated.

Local file/sync calls do not inherit the HTTPS timeout as a hard deadline; use bounded process supervision and inspect retained state after interruption. The exact notification contract documents directory checks, limits and recovery. A local inbox is a supported operator handoff, not a promise that an operator is watching it.

Configure a bounded webhook route

Keep the endpoint in an operator-provisioned environment variable, not in the repository or the route file. The route names that variable; it does not contain its value.

[[notification_routes]]
reference = "operations"
transport = "slack" # or "discord"
endpoint_secret_locator = "NQ_OPERATIONS_WEBHOOK_URL"
timeout_ms = 10000
max_response_bytes = 32768

Run nq --config ./nq.toml config check before submitting a prepared intent. Then use nq --config ./nq.toml notification submit --intent ./intent.json --route operations and nq --config ./nq.toml notification inspect --notification-id ID. Without --enable-network, submission records a refusal and does not resolve or contact the endpoint. A repeat of that event/destination reopens the existing record rather than becoming a future send.

The adapter makes one request: no automatic retry, fallback, redirects, or response-body logging. It requires HTTPS and bounds request duration. It does not consume the response body; the configured max_response_bytes value is not a verified bound on header or body transfer. See NQ’s notification guide for the intent contract, Nightshift enrollment requirements, and complete commands.

What was qualified, and what was not

Local Nightshift-to-NQ replay exercised receipt consistency without network delivery, including an exact duplicate and changed-receipt refusal. Deterministic Slack/Discord transports exercised the request and retained-outcome path. Upstream inputs in those cases were synthetic. Those checks demonstrate bounded local behavior; they do not show that a configured destination received a message, that a recipient read it, or that recurring monitoring is connected end to end.

Manual coverage while live delivery remains unqualified

1. Name the operator and the selected workflow's existing inspection entry point. Agree which failed, uncertain or overdue transitions need attention; do not infer an alert policy from an evidence stream.
2. Inspect the retained run or attempt through its owner. Preserve unresolved outcomes and reconcile before considering another submission.
3. Give the operator a minimal handoff: what happened, what needs attention, and an approved link or local reference to the relevant record. Exclude credentials, private prompts, raw evidence and unrelated campaign records.
4. Record acknowledgment separately if one is actually received. A file written to an inbox does not establish that anyone read it.

This is a manual operating procedure, not evidence of dependable live notification. The current alpha.6 governed-action profile does not include notification delivery, and one observed live delivery (2026-10-01) does not establish a dependable destination. See Operations and Troubleshooting for supported inspection and reporting paths.

Failures and recovery

Exact duplicate event/destination submissions converge on one retained record. Changed intent or message content under that identity refuses. Pending means no attempt has been claimed. For HTTPS, accepted means HTTP 2xx and failed means a non-success response. For a local file, accepted means exclusive creation plus file/directory sync; failed means creation failed before writing. Neither establishes human receipt. Unknown includes post-create uncertainty or a claimed attempt without a terminal result. Inspect before considering another action; do not invent a new event ID to work around uncertainty.

There is no retry daemon, delivery-failure alert loop, human acknowledgment, automatic resolution, escalation tree, or PagerDuty integration. Delivery failures remain inspectable locally, while an operator uses the manual handoff above. A live test needs separate approval of its exact message and destination; publication or model-provider approval does not authorize contacting a channel or paging people.

Saved local checks and maintenance declarations are separate, experimental NQ capabilities. The retained condition view keeps the original outcome, source-time assertion, local-read evidence and maintenance annotation distinct; coverage never changes a failed result or sends a message. See Saved checks for the public-only example and recovery procedure. The saved-check attention walkthrough now connects those interfaces through a finite Nightshift recurrence, exact attention replay and one real local-inbox delivery. It preserves the failed outcome under maintenance and qualifies duplicates and altered-receipt refusal. An unattended installation, application migration, live webhook delivery and human acknowledgment remain outside that evidence.