Staff Notification

What It Models

A staff notification records an application announcement and the people it reaches. The design groups application declarations, committed requests, personal notices and channel deliveries under one owner. Stored preferences and delivery configuration are facets of the same object, but they are dormant in this release.

Identity and Attributes

An application’s permanent key identifies a definition. A submitting service and repeat key derive a request identity, scoped by workspace. A time-ordered notice identity supports paging, while a separate occurrence digest enforces recipient uniqueness across partitions. Each notice has one delivery identity per channel.

Relationships

Association communications owns any future staff e-mail message; notification wording remains part of the staff declaration. Staff notice wording belongs to application declarations; association templates have no current notice reference.

Invariants

The invariant rows identify the guarantees supported by the cited evidence and the layer enforcing each one. They retain implementation gaps rather than treating intended behavior as complete enforcement.

How It Is Stored and Shared

Retirement settles requests without withdrawing their notices or queued deliveries. Unprocessed requests can dead-letter without appearing in History, and committed delivery outcomes can leave stale notice summaries. Reserved HQ scope, operator content access and future preference activation still need the recorded product decisions.

Open Design Questions

The module findings retain unresolved authority, recovery and source-boundary questions affecting this object.