The newsroom keeps the button. The desk keeps the log.
policy —
demo dataset
Everything here is synthetic
~1,000 generated readers, a week of editorial pushes, and lifecycle nudges — all produced by a seeded, deterministic builder (demo/build_dataset.py). No real reader data, no real publisher's editorial output.
User ids, names, stations, and quiet-hours timezones are invented.
Headlines are template-generated to look like a newsroom's daily mix; the two recurring "breaking" scenarios are generic enough to describe almost any market.
The decision log, caps, and disable-risk numbers you see are computed live by the same engine.decide() the unit tests exercise — the rules are real, the audience is not.
Rundown · what the desk would do right now
loading…
sendquiet hoursat capheldsuppressed
Loading…
Decision log · live
Loading…
Time
User
Class
Source
Status
Rule
Reason
Loading…
policy.json —
Every knob that governs push, in one file. The rule precedence is fixed and documented in engine.py; nothing here is applied ad hoc per candidate.
Compare: naive vs governed
"Naive" sends every candidate the instant it's generated — no caps, no quiet hours, no hold, no dedupe, no risk governor. P0 breaking news is identical in both runs, because the governed policy never throttles it either; this isolates exactly what Alert Desk's rules buy you, over the full synthetic week.
Loading…
What Alert Desk is, in plain English
Two streams
Editorial —
Programmatic —
Priority classes
Why this exists
The newsroom owns push. Product needs push to build a habit. Nobody arbitrates between them today — an editor and a lifecycle campaign can both message the same user in the same minute, and no one can say afterward why one landed and the other didn't. Alert Desk answers that with a rule, applied consistently, and a record of every decision it made, so the answer to "why did this user get five notifications yesterday" is a query, not a guess.