DISMISSED — OAD-1 — nothing says what a routine OUTAGE does to a dated condition that matured while the routine was dark, and the one rule that exists is conditioned on a declaration nobody can make retroactively

status: dismissed on the day it was raised · panel run 39 (2026-10-16), queue-and-clocks candidate C3, dismissed at the chair's adversarial pass · class: governance / registration hygiene (G5) · effort would have been ~0.1 pd of prose

The claim, in plain language

Thales has a rule for what happens to a deadline when the owner is away on purpose: ops/ABSENCE.md:30-32 — "expired items get flagged, never escalated to 'lapsed' — a deadline cannot lapse at a person who declared they are away."

It has no rule for what happens when a routine is dark. The absence rule is conditioned on a declaration. An outage is not declared, cannot be declared in advance, and cannot be declared afterwards without becoming the post-hoc edit C0 forbids. So a condition that came due inside a dark window has no governing rule, and the next reader must either invent one — which is gate-shopping — or read the date as lapsed, which silently discards the condition.

grep -rniE "outage" ops/*.md filtered for expiry/lapse/clock language returns zero hits. ABSENCE.md's own banner says it is "largely superseded 2026-10-07" and "must be revised" before December.

Two live instances, both created by the 2026-10-12 → 10-15 outage

• dismissed/trg-1 leg (a) is keyed to "the 2026-10-12 report", which does not exist — outbox/triage has no commit since 10-05. Its permanence clause ("if the 2026-10-12 and 2026-10-19 reports both carry the sweep, this dismissal becomes permanent") is therefore unsatisfiable as written: a condition designed to close itself can now never close.
• dismissed/hire-1: "Reopen automatically if frontier-cadence counter (c) fires on 2026-10-12." The substantive count reached 8 of 8 in the window ending 2026-10-11, the declaring routine (triage) was dark on 10-12, and "automatically" names no actor. This is the actor-less auto-reopen trg-1:57 already flagged, now with its date behind it.

Why it is dismissed rather than opened

1. The durable home is agent-denied, and that exact argument already killed a sibling. The rule belongs in ops/ABSENCE.md, matched by scripts/automerge_guard.py:68 (^ops/). No routine can merge it. The adversarial reviewer killed TRG-1 on precisely this ground — "spending a queue slot on something nobody in the loop can execute is implementation fantasy" — and that reasoning binds here. The two mitigations offered when this was raised (the queue is at 10/12 so no eviction is spent; the rule could live in queue/ and be routed to the owner as a NEEDS-OWNER: line) make the row cheaper, not executable, and cheapness is not the bar.

2. Its own kill criterion fires in three days, which is faster than any build. The criterion proposed with it was: if Monday 2026-10-19's triage handles hire-1 and trg-1 correctly with no written rule, the rule is unnecessary. Triage's own procedure already carries the instruments — the 14-day dismissed sweep (ops/QUEUE_TRIAGE.md:94-102, whose first real execution is that same Monday) and the counter-(c) declaration with its pre-committed action (:117-133). Opening a row to pre-empt a test that resolves on its own in three days is the quota behaviour NORTHSTAR.md §3 forbids.

3. The 2026-10-15 ruling is evidence the gap is already being closed without a written rule. Four conditions matured in or near the dark window and all four were answered by the owner on 10-15 (b927884), each pinned before its criterion was computed. The observed failure rate of "a matured condition gets mishandled after a dark window" is, so far, zero.

Reopen condition — this is the Monday test, pre-registered now

Reopen as a row if any of these becomes true:

1. The 2026-10-19 triage run does not name hire-1 and trg-1 in its decide-list, or names them and treats either date as simply lapsed — i.e. the condition is discarded rather than flagged-and-evaluated. First evaluation: the 2026-10-19 outbox report. If that report does not exist either, condition 2 applies instead.
2. A second dark window of ≥2 consecutive weekdays occurs (any routine, any cause) and at least one dated condition matures inside it — at which point this is the second instance of the class and the pattern is the finding, per rdr-1:128.
3. Any routine or session resolves a condition that matured in a dark window by moving its date, rather than reading it as-of its original date on the evidence then available. That is the gate-shopping this row exists to name, and one instance is enough.

The three-line rule, recorded here so it is not re-derived

Kept verbatim so that whoever does get to write ops/ABSENCE.md's December revision — which that file already demands — does not start from scratch, and so that condition 1 above has something concrete to be measured against:

(i) A dated condition whose evaluation date falls inside a window where its evaluating routine produced no beacon is FLAGGED, not lapsed, and is evaluated by the first run of that routine after the window. (ii) Its date does not move — the condition is read as-of its original date, on the evidence available then. (iii) A clause whose closure requires a report from inside such a window is re-cut by the owner or struck, never deemed satisfied.

Routed to the owner as a one-line ask rather than built: it is three lines of prose in a file no agent can merge, and ABSENCE.md needs its December revision regardless.

Adjacent ground — do not duplicate

CLK-1 (fired 2026-10-06) is clocks with no §6 row or evaluator. RDR-1 (permanently closed 2026-10-16 by its own never-reopen clause, now satisfied by ops/QUEUE_TRIAGE.md:94-102) is nobody reading dismissed conditions. TRG-1 is one prompt omitting one duty. RAD-1 (opened this run) is which inputs a pinned criterion counts. This row was the distinct question of dated conditions being unrulable after a dark window, and it is parked, not answered.