What the admin reads on clicking the bell: the in-app feed — a personal slice of delivered events, read state, actions. Channels, routes and types live on the notification settings screen; the delivery mechanics live in the dispatcher.
read_at IS NULL). The count updates instantly over the push channel (SSE), with polling as a background top-up. The in-app channel is locked on, so the bell is always present — feed = notifications ⋈ deliveries.
read_at on all of the admin's deliveries at once; the gear leads to the settings for channels and routes (edited by Owner only).
×N counter, not N rows. The key and window — the dispatcher's throttling.
notifications.meta). The event is shared across all Owners / Admins, and the action is global, so it is idempotent: the source of truth for scope is the Harvester allow-list; if the container is already in scope, a repeat does nothing and the “Add to scope” button dims for everyone. The notification itself does not store the action's state — the journal is not mutated for it. It lives only in the “Selected only” scope mode; in “Everything” mode the object is picked up on its own — then it is just info.
notifications.severity (critical · warning · info), color from the event catalog. The type on the left is the routing category (Sync · Security · Budget · System · Discovery).
source_ref: run, source, provider, budget. It takes you to where it gets fixed, straight from the feed.
read_at to the admin's own delivery — everyone has their own feed and their own read state, and others' are not touched. The event itself is append-only; it is neither edited nor deleted.
security and sync — is switched off in one's own profile (notification_prefs); there are no personal locks. The organizational lock on those two keeps in-app on at the organization level only — it can't be silenced centrally, but it does not constrain personal choice.