# 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:

| workflow | line |
|---|---|
| `paper-trading-meanrev.yml` | 192 |
| `paper-trading.yml` | 374 |
| `paper-trading-vrp.yml` | 137 |
| `fleet-digest.yml` | 119 |
| `heartbeat-monitor.yml` | 83 |

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.