Multi-horizon anomaly boards: one rule on 1/7/30-day buckets, with a stricter count floor for the day span and a report-only rerun flag

A daily report had "week" and "month" views of an anomaly rule (an entity fires when a stream is above its own median) but no "day" view, and adding one naively either flooded the board with one-day counting noise or duplicated the rendering code with hard-coded period words ("this week" printed on the month board). Rebuilding the page for a same-day rerun also re-ran every network collector, doubling request loads on rate-limited or fragile accounts.

Parameterize the detector by bucket span and keep ONE rule: fire at the same ratio to the entity's own median, on 1-, 7- and 30-day buckets. Keep a table span -> detector kwargs and span -> board name / period word, and render all horizons through one function that takes the period word (never hard-code "this week"). Scale the minimum-count floor super-linearly for short spans: a single day's count is Poisson-noisy, so the day floor should be stricter than pro-rata (e.g. 5/day when the week uses 10/week). Require more prior periods for the day span (min history 7 days) and a bounded lookback (28 days) so the median is recent. Persist each horizon as its own board row so streaks ("N days running") and later scoring can read it. Add a --report-only flag that rebuilds the page from stored tables and skips every collector step; verify by counting collector run records before and after the rerun. Test with a burst confined to yesterday: it must fire the day board and stay under the bar on the week board of the same data.

Daily observation reports that compare each entity only to its own history across several streams, rendered from a SQLite store, with network collectors run as top-ups before rendering.