--- id: CON-PFM-NOT-001 name: Notification Type feature: FEAT-PFM-NOT-01 product_area: platform module: notifications revision: 1 status: superseded product_intent: confirmed implementation_evidence: observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A retained description of the notification declaration facets now included within the broad Staff Notification concept. owned_by: MOD-PFM-NOT synonyms: - kind of notification - notification type not_to_be_confused_with: - A communication purpose defines the association e-mail a workflow requests. - 'A notification request, which is one occurrence of a definition' facets: - name: Application identity meaning: >- A permanent three-segment key identifies the notification type and the application that declares it. used_for: Separate application namespaces and preserve references across releases. - name: Preference category meaning: >- Nine recognized categories organize notification types, including assignments, approvals, jobs, billing, security and system. used_for: >- Group personal choices without changing the category of an established key. - name: Importance meaning: 'Info, important and critical express the notice''s severity.' used_for: Present urgency and support future quiet-hour decisions. - name: Configuration boundary meaning: >- Fully configurable, channel-configurable and mandatory modes constrain future choices. used_for: >- Preserve required defaults, including e-mail when that channel is supported. - name: Supported delivery routes meaning: >- A declaration identifies supported and default channels and always includes console support. used_for: Limit routing and explain channels that are unavailable or unsupported. - name: Permitted audiences meaning: >- Types cover individual users, user groups, responsibilities, roles and permissions; system declarations can address HQ. used_for: Validate the producer's method of selecting recipients. - name: Declared request fields meaning: A closed data schema accompanies one to ten representative examples. used_for: Check submitted data and exercise wording during registration. - name: Localized content meaning: >- Each channel has language-specific templates, with English as the baseline. used_for: Render content for the recipient's locale. - name: Navigation and actions meaning: Destination metadata describes the console route and additional actions. used_for: Connect the notice to the work that prompted it. - name: Repetition and lifetime meaning: >- Collapse, expiry and replacement settings control how an event stays useful. used_for: Reduce bursts and stop stale work. - name: Registration lifecycle meaning: >- Declared types are active; omitted types become retired and remain retained. used_for: Preserve history while targeting unsettled requests for cancellation. - name: Stored workspace customization meaning: >- Settings and published wording overrides exist in persistence but are not applied by the current pipeline. used_for: Provide configuration primitives for a later planned release. - name: Operational channel mapping meaning: Code maps system definitions to Rhythm's Slack channel keys. used_for: Route HQ alerts without customer configuration. relationships: - to: CON-PFM-NOT-003 statement: >- Submissions reference a single active declaration in the notification registry. provenance: test source: >- services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#records an unknown definition as invalid - to: CON-PFM-NOT-003 statement: >- Rendered recipient items inherit the registered content, category and severity. provenance: test source: >- services-platform:modules/notifications/tests/unit/render-message.spec.js#carries the severity, the record and the instant it happened - to: CON-PFM-NOT-004 statement: >- Product-authored notification content differs from association-authored communication templates. provenance: documented source: >- services-platform:docs/communications/architecture.md#22. Staff notifications: designed in the Platform Notifications architecture (2026-10-21) lifecycle: - state: active meaning: The declared type is usable for request processing. how_it_changes: Registration creates or reactivates a declared type. - state: retired meaning: >- An omitted type remains available to history while pending work receives best-effort withdrawal. how_it_changes: The next registration omits the type. acted_on_by: - CAP-PFM-NOT-001 - CAP-PFM-NOT-004 - CAP-PFM-NOT-013 - CAP-PFM-NOT-015 visible_to: - ACT-PFM-030 - ACT-PFM-029 - ACT-PFM-028 evidence: - >- Pinned evidence inventory 1: services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js; services-platform:modules/notifications/tests/unit/render-message.spec.js; services-platform:docs/communications/architecture.md; services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md supersedes: [] intent_sources: - 'services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#2. Scope' --- # Notification Type ## What It Is This record is superseded. The notification declaration is a facet of Staff Notification, and the permanent record remains available for historical references. The active staff model combines declarations, transactional requests, recipient items and delivery history. Applications need a shared description of the events they can announce before they submit live requests. A notification type supplies that description. It separates the stable identity of an event from any particular occurrence or recipient. The registration catalog therefore lets Platform validate a producer's contract and lets HQ inspect the notification vocabulary across applications. The declaration also places boundaries around data and rendering. A producer cannot treat a notification request as arbitrary prose addressed to arbitrary people. The registered type describes which audience forms, fields and delivery routes are available. Its wording belongs to the product rather than to an association editing its member e-mail. ## What It Is Not A notification type describes an event class, not a particular event or inbox item. Audience membership belongs to a submission. Association-authored e-mail belongs to the communication template model, where the workflow purpose and published wording serve a different recipient outcome. ## How It Is Used Application teams submit manifests during deployment. Platform checks schema shape, examples, channel wording and destination metadata before storing changes. HQ can read the shared catalog through controlled access. Definitions retain their permanent identity across releases, so retirement preserves historical references. Cancellation of pending work follows registration separately and can fail in an individual workspace. ## Its Facets **Application identity.** A permanent three-segment key identifies the notification type and the application that declares it. Separate application namespaces and preserve references across releases. **Preference category.** Nine recognized categories organize notification types, including assignments, approvals, jobs, billing, security and system. Group personal choices without changing the category of an established key. **Importance.** Info, important and critical express the notice's severity. Present urgency and support future quiet-hour decisions. **Configuration boundary.** Fully configurable, channel-configurable and mandatory modes constrain future choices. Preserve required defaults, including e-mail when that channel is supported. **Supported delivery routes.** A declaration identifies supported and default channels and always includes console support. Limit routing and explain channels that are unavailable or unsupported. **Permitted audiences.** Types cover individual users, user groups, responsibilities, roles and permissions; system declarations can address HQ. Validate the producer's method of selecting recipients. **Declared request fields.** A closed data schema accompanies one to ten representative examples. Check submitted data and exercise wording during registration. **Localized content.** Each channel has language-specific templates, with English as the baseline. Render content for the recipient's locale. **Navigation and actions.** Destination metadata describes the console route and additional actions. Connect the notice to the work that prompted it. **Repetition and lifetime.** Collapse, expiry and replacement settings control how an event stays useful. Reduce bursts and stop stale work. **Registration lifecycle.** Declared types are active; omitted types become retired and remain retained. Preserve history while targeting unsettled requests for cancellation. **Stored workspace customization.** Settings and published wording overrides exist in persistence but are not applied by the current pipeline. Provide configuration primitives for a later planned release. **Operational channel mapping.** Code maps system definitions to Rhythm's Slack channel keys. Route HQ alerts without customer configuration. ## How It Relates A submission names one registered, active type. Recipient notices use its templates, category and severity. Future personal and workspace settings are constrained by its preference mode, but their stored existence does not mean the current pipeline applies them. ## What It Could Become The product should plan workspace wording and preference controls before enabling the stored configuration. It should also resolve the retirement recovery gap and preserve a clear distinction between approved declaration policy and additional implementation validation. Action execution from external channels requires a separate permission and interaction design.