What Watcher remembers

Each watch keeps a small amount of state in the database. All of it exists to stop you being told the same thing twice.

What	Why it exists
Seen content hashes	So unchanged content is never re-evaluated
Notified event fingerprints	So one event produces one alert
Recent event embeddings (last 50)	So the same story reworded elsewhere is recognised
Event ledger (last 5 alerts, dated)	So the model knows what you have already been told
Last run time	So cron due-filtering works
Pending deliveries (max 10)	So an undelivered alert is retried

The consequence that surprises everyone

Content is evaluated exactly once, ever

Fresh content is marked as seen whatever the verdict was — triggered, not triggered, below threshold, duplicate. Watcher will never look at that content again.

So if a watch does not fire and you then improve the condition, nothing happens: the content that would have matched is already consumed. Only genuinely new content is judged against your new condition.

How to force a re-check

Pick whichever is least disruptive:

1. Wait for new content. Correct for an active feed, useless for a static page that already changed.
2. Change the source URL slightly (for example a different but equivalent listing page). Content memory is keyed on URL plus text, so a different URL is new content.
3. Create a new watch with a new id. A new id has no memory at all. This is the reliable, no-surgery option, and it keeps the old watch’s history intact.
4. Clear the stored state for that watch id directly in the database. Precise, but it also clears the notified-event memory — expect the next run to re-alert things you have already seen.

The event ledger

When an alert fires, Watcher appends a dated one-line summary to a ledger of the last five alerts for that watch, and hands the rendered ledger to the model on the next run as “already known”.

This is what stops a multi-stage watch from re-announcing an earlier stage. A watch following a process — announcement, then admit card, then exam, then result — keeps all recent stages visible to the model, rather than only the newest one.

Note

The ledger is durable state, stored with the rest of the watch’s memory, so it survives restarts and process boundaries.

State growth

Two of these lists are append-only and are not pruned today:

• seen content hashes — grows with every genuinely new item a watch sees
• notified fingerprints — grows with every alert (rare, so effectively small)

For a normal watch this is negligible for years. For a very busy watch — many new items every hour, indefinitely — the seen-hash list is the part that grows, and it is worth keeping an eye on if you run watches at that intensity. There is no automatic pruning or expiry.

What is not remembered

• Nothing lives in process memory between runs that matters. A restart loses only per-process key cooldowns, which self-heal.
• Run history is separate from run state: deleting a watch removes its definition, and its history rows remain.

Going deeper

• Deduplication — how these structures are used.
• Failures and retries — the pending-delivery queue in detail.
• Backup and restore — this state is the thing worth backing up.