A session’s notable prints on tracked tickers, each joined to the open interest its contract actually settled the next morning, and stamped opened, closed, rolled, unresolved or pending. The question a print raises is answered by OI, never by the print itself.
n. A verdict rate’s n is the number of distinct CONTRACTS, not prints, because prints on one contract share one settled change — the flow analogue of overlapping forward windows shrinking an effective n. Below n_min 20 the summary shows counts and no percentage.
Cost: three queries — the session, then the prints and the coverage together. Only point lookups touch core.option_strikes: rows D and D+1 by full primary key per contract, the persistence series by full key per later session, and — new, for the default above — the newest as_of_date per tracked symbol, a primary-key prefix read each. Measured on production 2026-09-16 at 18:53 ET: the session query 34–40 ms warm (62 ms cold), the prints query 240–470 ms for 2026-09-14’s 239 notable prints and 1,299 ms once for 2026-09-15’s 174 — the same spread of production load the 2026-09-15 numbers below show, not a change to the query. Measured warm on 2026-09-15, three passes: the session 32–37 ms; the prints query 278 ms for 09-11’s 203 notable prints at $500k and 365 ms for 09-14’s 239; 1,345 ms for 09-11’s 1,554 at the $100k floor, which is the page’s worst case and the reason the floor defaults where it does. Earlier the same day the same reads measured 237–311 ms and 850–1,000 ms; the spread is production load, not a change to these queries.
Flow Discovery asks the same session’s question of the names outside the universe, where no chain exists to answer it.
Counted in prints, not rated: prints on one contract share one settled OI change, so a rate’s n is the contract count in the table below, and R2 holds it to n_min 20.
| QQQ | 725C | 2026-08-21 | 7 | 16:03:59 | 1,499 | $1.5m | sweep | 1,499 | +1,027 | opened | — | 1 session — anecdote | tape not collected |
| AMD | 550C | 2026-09-18 | 35 | 15:58:41 | 337 | $770k | — | 337 | +792 | opened | — | 2 sessions — watching | tape not collected |
| QQQ | 750C | 2026-11-20 | 98 | 15:58:26 | 260 | $669k | sweep | 260 | +344 | opened | — | 1 session — anecdote | tape not collected |
| SMH | 550P | 2026-09-18 | 35 | 15:57:13 | 461 | $543k | sweep | 461 | +1,806 | opened | — | 4 sessions — information | tape not collected |
| MU | 880P | 2027-03-19 | 217 | 15:55:01 | 36 | $515k | — | 36 | — | unresolved | more than 120 days out; the chain is not collected that far | — | tape not collected |
Which session this page opens on. Session D’s alerts are collected at 21:15 ET that evening and the book that settles them at 19:00 ET the NEXT one, so a print is unjudgeable for about 27 hours — and on the newest alerted session every row below would read pending, which is this page’s subject missing rather than shown. With no ?date= it therefore opens on the newest session whose settling book has been collected — and whenever a newer session has alerts, the band above names it and says when it settles. Both run times are read from core.source_registry, the jobs’ own declared schedule. ?date= reaches every session, the pending one included.
The OI semantics, measured. Row D of core.option_strikes carries open interest at the START of D — OCC’s settlement of D−1 — so the change session D’s trading caused is oi(D+1) − oi(D). On none of the 108 notable contracts of 2026-09-11 that had both rows did row D+1’s prev_oi differ from row D’s oi. Row D+1 is written at 19:00 ET on D+1, and the collector re-fetches it the following evening and updates what changed (4 of 44,434 rows on the 2026-09-15 run), so a verdict can move exactly once. The next session’s chain has been re-fetched; the newest collected chain session here is 2026-09-25.
Why 50%. The settled change nets every trade in the contract — opening and closing, alerted or not — so “at least half the alerted size survived the netting” is the weakest claim that the alerts’ direction dominated the session. Declared, not fitted to make the table look decisive.
Why a roll needs a time link. The obvious rule — any same-ticker, same-type contract with same-session volume gaining OI within 25% of the loss — called 15 of 2026-09-11’s 16 closed contracts a roll, and each QQQ closure had 41–86 qualifying candidates. On a chain that deep a matching gain somewhere is the density of the chain, not a roll: the rarity-by-combinatorics trap DESIGN.md §3.5 cuts. Requiring the other leg to have drawn its OWN alert within 60s leaves two clean matches and admits nothing a 5-second window does not. The cost is recall: a roll whose new leg drew no alert stays “closed”.
Multi-leg reconstruction is not in the alert feed. DESIGN.md I pictures “of today’s 40 large SPY put prints, 31 were legs of verticals”. That read is not reproducible here: the vendor flags has_multileg on none of its RepeatedHits alerts (0 of 9,613 on 2026-09-14) and only on floor rules, and matching core.multileg_trades on ticker, second, strike, DTE and a size at least 50% of the print found 0, 0, 0, 0 and 2 prints over 2026-09-08..14 — the two the vendor itself flagged. Dropping the size floor finds 3–9 “matches” a session against trades a fraction of the print’s size, which are coincidences. So both counts are reported as they are, and the chain’s own per-contract multi-leg volume sits in each row’s tooltip as the only measure that sees every multi-leg lot.
n. A verdict rate’s n is the number of distinct CONTRACTS, not prints, because prints on one contract share one settled change — the flow analogue of overlapping forward windows shrinking an effective n. Below n_min 20 the summary shows counts and no percentage.
Cost: three queries — the session, then the prints and the coverage together. Only point lookups touch core.option_strikes: rows D and D+1 by full primary key per contract, the persistence series by full key per later session, and — new, for the default above — the newest as_of_date per tracked symbol, a primary-key prefix read each. Measured on production 2026-09-16 at 18:53 ET: the session query 34–40 ms warm (62 ms cold), the prints query 240–470 ms for 2026-09-14’s 239 notable prints and 1,299 ms once for 2026-09-15’s 174 — the same spread of production load the 2026-09-15 numbers below show, not a change to the query. Measured warm on 2026-09-15, three passes: the session 32–37 ms; the prints query 278 ms for 09-11’s 203 notable prints at $500k and 365 ms for 09-14’s 239; 1,345 ms for 09-11’s 1,554 at the $100k floor, which is the page’s worst case and the reason the floor defaults where it does. Earlier the same day the same reads measured 237–311 ms and 850–1,000 ms; the spread is production load, not a change to these queries.
Flow Discovery asks the same session’s question of the names outside the universe, where no chain exists to answer it.
Simplify Analytics