ADR-0019: Notifications & Tasks¶
- Status: accepted
- Date: 2026-06-18
- Deciders: Nicolas Burri
- Extends: ADR-0005; relates to ADR-0003, ADR-0015, ADR-0016; GAP-07
- Refined by: ADR-0034 (in-process domain events + system-context fan-out), ADR-0037 (REQ-NOT-004 reminders/escalation — in-process tick, advisory-lock election, SQL sweep), ADR-0041 (notification-as-outbox, structured messages, the email channel)
Context¶
Several decisions already assume a notification mechanism: base-update notification (REQ-DOC-012), revocation-of-source (REQ-LC-013), overdue-review surfacing (REQ-EFF-007), disposal-due (REQ-DPR-005). And the daily-work usability goal (STR-007) needs users to see what they must do. Nothing specified how.
Decision¶
Introduce a notification module (a new building block, extending ADR-0005) providing two distinct concepts:
- Task — an actionable item tracked to completion. Generated from domain events
(review requested, approval/signature required, rejection, periodic-review due/overdue,
disposal-due, derivation source updated/revoked); assigned to the role(s) the applicable
review policy requires (any holder may act) or to a specific user; has state
open → done / cancelled; auto-resolves when its underlying action completes or no longer applies; supports configurable reminders and optional escalation when overdue. - Notification — an informational message (e.g. "base SOP-007 v4 released"); tracks read/unread; may reference a task or event.
Cross-cutting rules:
- Scope-keyed and under RLS (ADR-0009): a user sees only tasks/notifications for scopes they are authorized for.
- Delivery: an in-app inbox always, plus a pluggable channel interface with an email implementation configured per deployment; further channels (webhook/chat) fit the same interface. Absence of email config must not impair in-app delivery.
- Event-driven: other modules emit domain events; the notification module consumes them (keeps coupling low and the module an extraction candidate like search).
- Operational, not the record of truth: tasks/notifications are a convenience layer;
the authoritative record of actions remains the audit trail (
AUDIT_EVENT), so they are not subject to record retention.
Options Considered¶
- Single unified inbox (rejected): simpler, but loses first-class tracking of outstanding obligations ("what is still pending for me"), which QMS daily work needs.
- In-app only, no email (rejected for the design; email impl may still be staged): users would have to open the app to discover time-sensitive review/approval tasks.
Consequences¶
- New
notificationmodule +TASKandNOTIFICATIONentities (arc42 §5, §8.1); a domain-event mechanism between modules; a delivery-channel abstraction (like the storage/LLM pluggability). - Reminders/escalation need a scheduler (also useful for periodic-review/disposal due dates).
- The email channel's actual delivery is deployment configuration; the spec requires the capability, not a specific mail server.
Requirements¶
Introduces STR-023 and the REQ-NOT group (pending requirements baseline v1.2).