DISMISSED — DSP-1 — the Mac dispatch layer half-failed on three consecutive sessions and no machine noticed; considered as a loudness row and REJECTED

status: dismissed at adversarial review, panel run 25 (2026-09-17) · class considered: loudness & safety (G2) · the mechanism claims are all TRUE; the row is killed on severity, duplication and an unverifiable premise, not on facts

What was considered

On 2026-09-02 two launchd agents were added to the owner's Mac to fire the time-sensitive workflows at their intended market times via gh workflow run, because GitHub's own schedule: events had been arriving 3–9 h late and three of five sessions traded after the close (RUNBOOK.md:21-38). The proposal was that this layer can degrade silently, and has been degrading:

Verified against the Actions API as well as the commit timeline: paper-trading-vrp.yml has a workflow_dispatch at 14:35Z on 09-09, 09-10, 09-11 and 09-15 and none on 09-14 or at 14:3xZ on 09-16; skew-snapshot.yml has workflow_dispatch runs on 09-03/04/07/08/09/10/11/16 and none on 09-14 or 09-15.

The mechanism claims — all verified TRUE, recorded so nobody re-derives them

1. ops/launchd/com.thales.dispatch-trading.plist:10-17 — one agent dispatches all three trading workflows in order.
2. scripts/dispatch_workflows.sh:73-87 — rc comes from gh workflow run's exit code only, and beacon success fires iff every call exited 0. The beacon attests SEND, never RUN CREATION.
3. scripts/dispatch_workflows.sh:44-53 — the beacon URL is optional and read from config/.env; absent = silently disabled ([ -n … ] || return 0).
4. RUNBOOK.md:81-96 — the beacon inventory table has 14 rows and no HEALTHCHECK_URL_DISPATCH row, directly below RUNBOOK.md:76-79's own warning that "an unconfigured beacon reads as coverage while providing none." The secret appears exactly once in the repo outside the script (RUNBOOK.md:37) and is absent from ops/launchd/README.md's beacon setup.
5. scripts/detect_runner_loss.py:106,257 — the only mechanical run-level sweep filters event != "schedule", so the dispatch leg is outside it by construction.
6. src/thales/execution/fleet_digest.py:1157-1189 — digest_exceptions has no timeliness leg, and the DID-NOT-RUN detector fires only when a sleeve has no run record for the day, which the backup cron prevents.

Why it was killed anyway

1. Zero realized harm, and the backstop worked every single day. Every session in the window traded in-session: the latest was momentum 19:48Z on 09-14 = 15:48 ET, and vrp's 09-16 make-up ran 17:24Z = 13:24 ET. The layer this row defends is a convenience over a working fallback, not a control. Contrast the regime it was built for (08-27→09-01), where three of five sessions traded after the close. Arguing urgency from a degraded convenience whose backstop held is severity inflation.
2. It is BCN-1 twenty-four hours later. dismissed/bcn-1-liveness-beacon-gated-on-job-success.md was dismissed by panel run 24 on 2026-09-16 on materially this argument — a beacon-coverage gap, backstopped by a channel that actually fired, against a 12/12 cap. None of BCN-1's three reopen tripwires is satisfied here. Opening a near-twin the next day is exactly the padding ops/RESEARCH_PANEL.md names.
3. The load-bearing premise is unverifiable here, and the live evidence cuts against it. config/.env is absent from the routine container, so whether HEALTHCHECK_URL_DISPATCH is configured is NOT-VERIFIABLE. The 09-16 17:22:59Z re-dispatch was vrp-only, not the agent's three-workflow batch — i.e. a targeted human action, which is positive evidence that something did reach the owner. A row headlined "nothing notices" cannot rest on a fact the container cannot check while the contrary reading sits in the same evidence.
4. The expensive half is the weakest half. A repo-side run_started_at-vs-intended-time detector is ~0.5–1 pd of gh api plumbing. dismissed/cron-delay-capture.md is not a C0 bar on it (a detector is not a research capture stream, and neither of that dismissal's two reopen tripwires has fired), but its third argument stands: the legitimate ops value is already captured free — every audit memo timestamps these delays, and the daily audit found this one by eyeball the same evening.

Kept out of the queue, handed over instead

• One line to the owner, in this run's report: confirm whether HEALTHCHECK_URL_DISPATCH is configured — the skew agent produced no run on both 09-14 and 09-15, and the trading agent missed vrp on 09-16. If that beacon is not set, three silent half-failures in three sessions is what its absence looks like.
• A docs one-liner in passing: add the HEALTHCHECK_URL_DISPATCH row to RUNBOOK.md's beacon inventory table with its check spec, so the beacon stops being the one that is on no list to verify.

Neither is a research item and neither needs a slot.

Reopens if

• (a) a session ever trades after the 16:00 ET close with the dispatch layer having failed silently — the harm this row could not demonstrate; or
• (b) the owner confirms HEALTHCHECK_URL_DISPATCH is not configured, which converts claim 3 from unverifiable to established and leaves the dispatch layer with no liveness signal at all; or
• (c) a dispatch is shown to have exited 0 with no run created (the Mac's logs/dispatch.log says dispatched <wf> for a workflow with no corresponding Actions run) — that is the "beacon that cannot fail" shape, which no amount of backstop argument excuses; or
• (d) BCN-1's own reopen conditions fire, since the two rows would then merge into one structural question about the liveness layer.

The data-side consequence of these same three sessions is NOT dismissed: it is open/cqa-3-capture-qa-blind-to-capture-instant.md, which stands on its own evidence and its own kill criterion.