DISMISSED — B4-NOTCH — the skew stream's calendar notch, and the ≥400-row floor it put in question

status: dismissed by TRIAGE 2026-08-24 · resolution: the floor is AFFIRMED BY SILENCE, per the item's own pre-registered default · raised panel run 1 (2026-08-06) · body verbatim below

Resolution — the item's own default fired today

Killed because it resolved itself, exactly as designed. The item pinned a forcing function: "The ≥400-row floor must be affirmed or amended, countersigned, by a date pinned now, and in any case before the first skew-vs-return computation. Silence resolves to AFFIRM." Triage run 2 (2026-08-17) attached the date: unless the owner pinned an affirm-or-amend date or amended the floor by 2026-08-24, run 3 records the floor as AFFIRMED BY SILENCE and stops carrying it as a weekly decision.

Verified today, 2026-08-24. No commit since 2026-08-17 touches research/2026-08-01_b4_skew_activation_pin.md (last touched 2026-08-14 by an unrelated skew snapshot), the ≥400 floor at :71 is unchanged, and no affirm-or-amend date was pinned anywhere. Silence held for the full window.

What is now on the record, and must survive to the 2027-06 first read:

• The ≥ 400 valid-skew-rows floor STANDS as registered, affirmed by silence on 2026-08-24.
• ISO week 27 (2026-06-29 … 2026-07-06) is skipped entirely by the pinned primary statistic — six consecutive days at 283 valid rows, below the floor. That is ~11% of accrued weeks, and it is known-at-registration, not a discovery to be made after seeing a return.
• The 283-name set was checked and cleared: byte-identical across all six days and a strict subset of the ~890-name set — a genuine calendar notch (only names with weeklies qualify), not a silent cap, and therefore not a sibling of CQA-1.
• The adjacent risk stands unexercised: the pin drops an observation when consecutive signal dates are more than 10 trading days apart, and the week-26 observation chained 06-26 → 07-10 = exactly 10 td, on the boundary. A 7-day notch would have cost the adjacent observation too.

Recorded here rather than in the pin memo on purpose. The pin is hash-frozen; appending to it would be the C0 breach the default exists to avoid. This file plus git history is the durable record, and it is the record the 2027-06 checkpoint should read alongside the pin.

Reopens if: (a) the owner countersigns an amendment to the ≥400 floor before any skew-vs-return statistic is computed — affirm-by-silence closes the weekly decision, it does not forbid a countersigned amendment ahead of the first read; or (b) a second calendar notch destroys a further accrued week, so that cumulative loss materially exceeds the ~11% recorded here; or (c) the 2027-06 checkpoint finds the floor is biting for a reason other than the weeklies-only calendar effect cleared above.

Body as raised (verbatim from the frozen archive)

5. ⚠ EXPIRES · B4-NOTCH — the skew stream's calendar notch has already destroyed 1 of 9 accrued weeks of a hash-frozen test, and the option to say so expires. · judgement: YES · effort 0.25 pd (memo only) · horizon: pin a date now

Measured from owned committed data (data/options_skew.jsonl, 42 dates):

ISOwk 27 (06-29…07-03):  283 283 283 283 283   ← all five below the 400 floor
2026-07-06:              283                    ← six consecutive days
2026-08-03:              281                    ← one-day notch
all other days:          888–897

B4's activation pin (research/2026-08-01_b4_skew_activation_pin.md:71) requires ≥400 valid rows for a signal date, so ISO week 27 is skipped entirely by the pinned primary statistic — ~11% of accrued weeks gone from an already screen-grade test whose first read is 2027-06. The pin also drops an observation when the gap between signal dates exceeds 10 trading days, and the week-26 observation chained 06-26 → 07-10 = exactly 10 td, landing on the boundary; a 7-day notch would cost the adjacent observation too.

Checked and cleared: the 283-name set is byte-identical across all six days and a strict subset of the full 890-name set — exactly what "only names with weeklies qualify" predicts. It is a genuine calendar notch, not a silent cap, and therefore not a sibling of CQA-1.

Kill criterion — a forcing function, because report-only means this resurfaces in 2027-06 when amending is no longer possible without a C0 breach. The ≥400-row floor must be affirmed or amended, countersigned, by a date pinned now, and in any case before the first skew-vs-return computation. Silence resolves to AFFIRM — pin stands, notch accepted, the ~11% loss recorded as known-at-registration. Default-to-affirm is what stops the option being exercised after someone has peeked at a return.

Owner judgement required, and it is the only item here that expires.

2026-10-01 append — REOPEN CONDITION (b) HAS FIRED, and the 2026-09-18 observation was never saveable

Recorded from the panel-run-31 check-in. This append exists because three consecutive panel runs (29, 30, 31) and the daily audit headlined a rescue deadline that the calendar made impossible, and nobody checked feasibility. Two of those runs were mine.

What happened

The 2026-10-01 skew capture landed (Actions returned when the allowance reset). It carries 281 valid rows — below this item's ≥400 floor. It is therefore not a signal date, and ISO week 40 still has none.

Why Friday 2026-10-02 cannot fix it, measured

The B4 pin (§2) takes the single expiry nearest 30 days, window 20–45 days. Monthly options expire the third Friday. Measured from the committed capture:

• 2026-09-18: all 888 rows used expiry 2026-10-16 (the October monthly), dte 28.
• 2026-10-01: all 281 rows used expiry 2026-10-30 (a weekly), dte 29 — because no monthly third Friday falls in the window at all. The 281 names are a strict subset of the 888, overlapping 277 with the June notch set: the same weeklies-only population this item already characterised.

Third Fridays: 2026-09-18, 2026-10-16, 2026-11-20. For every session from 2026-09-28 through 2026-10-05, Oct 16 is nearer than 20 days and Nov 20 is further than 45 — so no monthly expiry is in window and only weekly-listed names produce a row. The first session that recovers is 2026-10-06, where Nov 20 sits at exactly 45 days.

So every day of ISO week 40 is a ~281-row notch day, Friday 10-02 included. The next possible qualifying signal date is 2026-10-06 — trading day 12 from 09-18, and the pin drops the observation past 10. The 2026-09-18 observation was unsaveable from the moment the exchange calendar was set. The Actions outage did not cost it; the outage cost W39.

The error, stated plainly

The trading-day arithmetic (09-18 → 10-02 = exactly 10 td) was re-derived four times across runs 29–31 and is correct. Nobody asked whether a ≥400-row capture on 10-01 or 10-02 was achievable — including run 31, which read this very file, quoted its ≥400 floor and its weeklies-only characterisation, and still did not check the expiry calendar. A deadline is not actionable until the remedy is shown to be possible; "margin is 2 sessions" was arithmetic about the wrong quantity. Two owner notifications went out on that basis.

Reopen condition (b) now fires on its own terms

This file's clause (b): "a second calendar notch destroys a further accrued week, so that cumulative loss materially exceeds the ~11% recorded here." W40 is a second calendar notch and it destroys a week — not an outage, the mechanism the clause names. Census of completed weeks W24…W40:

Notch-only already exceeds the ~11% anchor (which was 1 of 9), on the clause's own mechanism. Run 31 recorded (b) as NOT-FIRED at 2 of 16 = 12.5% because W40 was then incomplete and believed saveable. It is now complete and was never saveable. (b) is FIRED. Reopening is triage's mechanical call, not a check-in's, and the queue is over its 12-cap — this append is the record that the condition fired, with its measurement, for the next panel and the 10-05 triage.

The forward number nobody has computed, and it is the decision-relevant one

The notch is periodic and predictable, roughly quarterly. ISO weeks in which every session is a weeklies-only notch — i.e. structurally incapable of yielding a signal date, with perfect uptime:

(2026, 27)  2026-06-29 .. 2026-07-02      (2027, 26)  2027-06-28 .. 2027-07-02
(2026, 40)  2026-09-28 .. 2026-10-02      (2027, 39)  2027-09-27 .. 2027-10-01
(2026, 53)  2026-12-28 .. 2026-12-31      (2027, 48)  2027-11-29 .. 2027-12-03
(2027, 13)  2027-03-29 .. 2027-04-02

5 dead weeks before checkpoint 1 (of 56 spanned, 8.9%) and 7 before checkpoint 2 (of 82, 8.5%). So the pin's printed premise of N ≈ 54 at checkpoint 1 is structurally capped at 51 by the exchange calendar alone, before a single outage day — and three of those five dead weeks are still in the future, so they are forecastable rather than discovered.

This is known-at-registration information in exactly the sense this item's original body used that phrase, and it was available on 2026-08-01. It does not change any threshold and must not: the pin is append-only and re-cutting N or the bar after seeing a loss is the gate-shopping the pin exists to prevent. It changes only what a reader should expect, and it should reach the 2027-06 checkpoint alongside the pin.

Also recorded so a future panel does not mis-handle it: W53 (2026-12-28) is the next dead week and it is 12 weeks out. No rescue exists for a notch week — no capture on any of its sessions can clear the floor — so a future run must not escalate a notch week as an uptime deadline. Uptime deadlines and notch weeks are different failures with different remedies, and conflating them is what produced this append.

Reopens further if

• (d) the structural dead-week count before checkpoint 1 rises above 5, or any dead week proves to have a qualifying session after all — either falsifies the table above, which is computed from third-Friday arithmetic and should be re-derived, not trusted;
• (e) the owner countersigns any amendment touching the ≥400 floor or the 10-trading-day gap rule, at which point this census is the input to it.

ANNOTATION 2026-10-02 — panel run 33: this file's ATTRIBUTION is wrong. The outage cost TWO observations; the notch cost one.

The structural half of this record is confirmed, independently and twice (see the panel run 33 report): the dead-week table, the 5-of-56 / 7-of-82 counts, the N ≈ 54 → 51 cap, and W53 = 2026-12-28 all reproduce exactly from third-Friday arithmetic plus the repo calendar, and reopen clause (d) does NOT fire. The forward map is also complete — 2027-W13 and 2027-W26 were already in its own table — and the 51 figure is invariant to both the checkpoint-boundary convention and the Juneteenth expiry shift. One model-validation detail worth keeping: over all 72 accrued capture dates the predicate "no monthly third Friday in the 20–45d window" and the observed "<400 valid rows" agree on 71 of 72, the single divergence being the already-recorded 2026-08-07 capture-date collision, whose 5 rows used expiry 2026-09-18 — i.e. the model predicts it correctly.

The prose does not survive. :128-129 states "The 2026-09-18 observation was unsaveable from the moment the exchange calendar was set. The Actions outage did not cost it; the outage cost W39." That is false. Under perfect uptime the signal-date chain is W38 = 09-18 → W39 = 09-25 → (W40 dead) → W41 = 10-09, with gaps of 5 td and 10 td. §3 drops an observation only when a gap exceeds 10 — this file's own boundary reading at :126-127 — so both 09-18 and 09-25 survive the W40 notch on the calendar alone. What killed 09-18 is that W39 has no capture at all, because of the billing outage, making the realised chain 09-18 → 10-09 = 15 td. The notch is a necessary co-factor, not the cause.

Trading-day counts, derived three times independently (two panel lenses and the chair, all from thales.utils.calendar): 09-18→09-25 = 5, 09-25→10-09 = 10, 09-18→10-09 = 15, 09-18→10-05 = 11. The conclusion is invariant to the one convention that was not pinned down: this file says at :122-123 that the first recovering session is 2026-10-06, while the chain above uses W41 = 10-09; under either, 09-25's next qualifying date is 7 td or 10 td away, neither exceeding 10.

Correct attribution: outage 2 observations (W38's and W39's), notch 1 (W40's) — not 1 and 1.

Consequences, none of which move a decision:

• Realised N at checkpoint 1 caps at 49, not this file's 51 (a perfect-uptime figure) and not the pin's printed 54. E[t] falls by √(49/54) = 4.8% (λ = 0.15 → 1.05 vs 1.10). As run 32 concluded about the same episode from the other side, this changes the decision in neither direction.
• :152's "total lost 3 of 17 = 17.6%" is never reconciled against that realised cap; it is the same perfect-uptime/realised conflation one layer down.
• The live linkage, which is why this correction was also sent to the owner rather than only filed: if the billing outage cost two of 17 accrued weeks rather than one, the recurring allowance exhaustion (#191, forecast ~the 20th) is measurably more expensive to this capture programme than this record prices it.

No threshold moves and nothing is re-cut. Re-cutting N after seeing a loss would be gate-shopping; this annotation corrects a stated cause, which is the one class of defect a shop whose markdown is executable cannot leave standing. This file remains DISMISSED and its reopen conditions are unchanged.

Forward, verified and additive: every dead week is a zero-margin point under the 10-td rule. Bridging one on perfect uptime is 9–10 td against a bar of 10, so a notch week in isolation costs exactly one observation, but any adjacent lost week pushes the bridge to ~14–15 td and costs a second — which is precisely what happened here (W39 outage + W40 notch = 15 td). Bridges for the three future dead weeks, re-derived by the chair: W53 12-24→2027-01-08 = 9 td; 2027-W13 03-25→04-09 = **10 td**; 2027-W26 06-25→07-09 = 9 td. None costs its neighbour on perfect uptime, and 2027-W13 has no margin at all. The operating consequence is a date, not a rule: planned downtime must not land in 2026-W52 (Dec 21-24) or 2027-W01 (Jan 4-8), the weeks flanking W53.

Append 2026-10-07 (panel run 36) — the forward recovery prediction is CONFIRMED, on its predicted date, to the day

:107-130 predicted from the exchange calendar alone — before the fact, with no market data — that every session 2026-09-28 → 10-05 would be a weeklies-only notch day near ~281 rows, and that "the first session that recovers is 2026-10-06, where Nov 20 sits at exactly 45 days."

Measured this run from the committed store:

The notch ended on exactly the predicted session. 10-05 is 282 rows, below the ≥400 floor as predicted; 10-06 is 882, of which 601 carry expiry 2026-11-20 at DTE exactly 45 and 281 a weekly (2026-11-06, DTE 31). 10-05 misses the recovery by a single calendar day.

Two consequences worth having on the record where the 2027-06 checkpoint will read them:

1. ISO week 41 has a qualifying signal date. W40 (10-01 = 281, 10-02 = 282) carries none and is a lost week. W41 (10-05 = 282, 10-06 = 882) is saved by the recovery session — which arrived via the late backup cron at 22:57:52Z, post-close. So no further accrued week is lost to this notch, and reopen clause (b) does not fire a second time.
2. The periodicity model that generated the forward dead-week calendar is now validated once out-of-sample. That calendar's next entries (W53 / 2026-12-28, then 2027-W13, W26, W39, W48) should be read as having one confirmed forecast behind them rather than none.

What this append does NOT do. Clause (a) — an owner countersign on the ≥400 floor, required before any skew-vs-return statistic is computed — remains available and unspent, and this confirmation neither discharges nor strengthens the case for spending it. The row count is a calendar artifact; it says nothing about whether 400 is the right floor. That question is still open/cqa-3's neighbour and the owner's.

One thing that must not be inferred from the 882. It is tempting to read "the late capture returned three times the rows" as evidence that post-close capture is harmless or even better. It is not evidence either way: 10-01 and 10-02 were captured in-session and still returned 281/282, while post-close 10-06 returned 882. The two mechanisms are independent — expiry calendar for the row count, dispatch timing for the capture instant — and conflating them would corrupt exactly the threshold judgement open/cqa-3 is waiting on.