Notification Delivery Policy

Arinova notifications have three product delivery surfaces: the in-app feed, realtime WebSocket updates, and mobile/browser push. A notification type may be filtered by the global switch, its per-type switch, conversation settings, and work or quiet hours before it reaches those surfaces.

Social activity

Friend requests, friend acceptance, group invitations, mentions, thread replies, and unread chat activity are in-app/realtime/push events. They do not send an outbound email to the user’s account address. Authentication and security emails (for example verification and account recovery) are separate transactional flows and are not controlled by notification preferences.

email_* preference names

The email_received, email_quarantined, email_reply_failed, and email_quarantine_full notification types describe events from the Agent Email inbox product. Their notification_preferences.email_*_enabled columns toggle those event types on the ordinary notification surfaces; the email prefix is the event domain, not an outbound-email delivery channel.

Adding account-email delivery is therefore a separate product and privacy decision. It must define consent, templates/localization, unsubscribe behavior, rate limits, and delivery observability instead of reusing the Agent Email event toggles.

Cron failure results

Cron skips, timeouts, terminal delivery failures, and automatic pauses use one failure-visibility pipeline. Each occurrence broadcasts a cron:failed WebSocket event, creates a cron_result feed notification, and attempts push under the existing cron_result_enabled, global, and quiet-hours preferences. Consecutive unread failures with the same job and reason fold under cron:{job_id}:{reason}; a different reason, including auto_paused, remains a separate notification. Agent-less Workflow jobs use system attribution rather than inventing a sender Agent.

Manual skipped fires are committed before notification begins. The fire row’s durable notification marker is set in the same transaction that creates or folds the feed item, and push uses a stable fire-event identity. Retrying the same manual idempotency key therefore repairs a commit-to-notification crash window while leaving an already-recorded notification unchanged. Successful manual replay does not rebroadcast normal fired or lifecycle updates.