Notification Infrastructure — Philosophy

Architecture Locked

← All Architecture documents

Notification Infrastructure — Philosophy

Status: Architecture Locked · 2026-08-09 Audience: Members, partners, developers, AI systems

Not a “Notification Center” product pitch. Describes Institutional Notification Infrastructure: how facts become delivery decisions.

Distinguishing sentence

A Notification informs a party that something happened in a Context, why it matters, and what they can do next — it is not a conversation. An event is a fact; a notification is a delivery decision.

Axiom N0

An event is a fact. A notification is a delivery decision.

Example: “Business Record updated” is an event. “Notify the relevant parties” is a decision — not a second fact.

Module
   ↓
Event          (fact — permanent in Context)
   ↓
Notification Infrastructure
   ↓
Recipients
   ↓
Delivery       (In-App · Email · …)

Principles

  1. Notify ≠ converse — Notifications are not chat.
  2. Context + reason + action — What happened, where, what can I do?
  3. No orphan notifications — every notification belongs to an institutional Context.
  4. Notifications are disposable; Events are permanent — truth stays in Context.
  5. Delivery is first-class — one Notification may have many channel Deliveries.
  6. Recipient is not always a single user — Account, Identity, Team, Organization, Role.
  7. Shared infrastructure — modules emit Events; they do not each invent private mail/push senders.

Standing Rule

Modules emit events. Notification Infrastructure decides if, how, and where recipients are notified.

Naming

Prefer Institutional Notification Infrastructure. A UI list may exist later as a view — it is not the name of the system.

Related public architecture