BCN-1 — the liveness beacon is gated on job SUCCESS in five workflows, so a post-trade reporting failure withholds the "did it run" signal

status: dismissed by PANEL run 24 (2026-09-16), at its own adversarial review, before reaching the queue · class: loudness (G2) / detector coupling · never occupied a row in queue/open/ — filed here so the measurements are not re-derived and the reopen valve is visible to ls

Plain-language summary for an owner reading one paragraph. Every scheduled job pings healthchecks.io at the end of its run; that ping is the only thing in the system that proves a job ran at all. In five workflows the ping is gated on the whole job having succeeded. In the two sleeve workflows the reconcile step runs after trading is done and state is committed — so a failure in a post-trade report withholds the liveness signal, and the sleeve reads as "never ran" when in fact it traded normally. That is what happened to meanrev from 09-11: a false drift alarm (the defect PR #171 addresses) held thales-meanrev DOWN for four days. A detector defect disabled a detector. This is dismissed anyway, because the owner was in fact paged on all three red days through a channel that does not depend on the beacon, and what is left is a design question only the owner can answer.

Mechanism — verified at HEAD 7fd0d74

if: ${{ success() }} guards the healthchecks ping at:

In the sleeve workflows thales portfolio reconcile runs if: always() after Persist sleeve state, so the ordering is: trade → persist → commit → report → beacon. A red report reaches back past three completed steps and suppresses the beacon.

Why it is dismissed — the backstop is real, and it fired

paper-trading-meanrev.yml:203-210 runs the shared _alert.yml on always() && needs.trade.result != 'success' && != 'skipped'. It emails independently of both the beacon and the fleet digest, and it fired on 2026-09-11, 09-14 and 09-15. Separately, fleet_digest.digest_exceptions (fleet_digest.py:1171-1172) lists no_run_sleeves as an exception that forces a same-day email even under the new weekly cadence. So the owner was never actually un-pushed — which also corrects the claim in PR #171's memo that "a genuinely missed meanrev run would have looked identical." It would not: the two states are identical only on the healthchecks channel, not on the fleet's.

What remains is a genuine design ruling with no defect behind it: should a liveness beacon mean the process ran or the process ran clean? Decoupling them trades the false-red this fixes for a new false-green risk (a job that runs, fails, and still reports alive). That is an owner call, not a bug, and minting a row for it at a 12/12 queue would displace an incumbent that has one.

Reopen condition

Reopen as a row if any of these becomes true:

1. a beacon is withheld on a day when the _alert path also fails to deliver (the backstop is what carries this dismissal — if it lapses, the dismissal lapses with it);
2. any sleeve's beacon stays down ≥3 consecutive sessions for a cause outside the reconcile window-edge class that PR #171 addresses;
3. the owner rules on the semantics and wants the decoupling implemented — at which point this is a build item, not a question.

Adjacent ground, do not duplicate: DGX-1 (open) holds the digest-gate blindness, including the missed=None "no readable beacon" leg; FOS-2 (dismissed) holds the per-sleeve streak split.