Rhythm 2.0 Specifications

Appearance

CAP-PFM-NOT-007Route and send notification deliveries

Markdown

CAP-PFM-NOT-007

Route and send notification deliveries

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationPartially observed

Planning

Feature
FEAT-PFM-NOT-02
Key concepts
CON-PFM-NOT-003
Actors
ACT-PFM-031
Journeys
JNY-PFM-NOT-003
Depends on
CAP-PFM-NOT-003
Related
CAP-PFM-NOT-012, CAP-PFM-NOT-013, CAP-PFM-NOT-015, CAP-PFM-NOT-008
Proved by
ATS-PFM-NOT-007
Executed by
TST-PFM-NOT-074, TST-PFM-NOT-075, TST-PFM-NOT-079, TST-PFM-NOT-085, TST-PFM-NOT-086, TST-PFM-NOT-089, TST-PFM-NOT-105, TST-PFM-NOT-108, TST-PFM-NOT-110

KindCapabilityProduct areaPlatformModuleStaff Notifications and Association CommunicationsRevision1

Read atservices-platform ad3f6a65react-console baf6dae3

Route and send notification deliveries ​

Purpose ​

Platform records channel selection and delivery progress while keeping unavailable channels explicit.

How It Works ​

Platform resolves channels against the definition and installed adapters. Personal delivery currently chooses the console. Unavailable channels retain an explanation instead of silently disappearing. Installed adapters report whether they can reach the destination. Queued channels hand due deliveries to their dedicated work mechanism. A consumer locks a delivery before sending and treats repeated final items as completed work. Temporary failures use bounded retry while permanent refusals stop immediately. Delivery events and aggregate notice status record progress independently of personal read state.

The rule rows define this outcome; the acceptance set identifies existing proof and proposed checks. Implementation evidence alone does not approve the observed details.

Relationships ​

Recipient selection supplies the eligible people and their audience explanations.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Channel work records delivery progress and adapter outcomes.Retries and event deduplication limit repeated processing within the implemented safeguards.
Surfaces
job
Intent sources
services-platform:docs/proposals/notifications/23-decisions.md#D-02services-platform:docs/proposals/notifications/23-decisions.md#D-09services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#4. Assumptions

Controls

27 controls apply, from the corpus control catalogue.

TC-AVL-001 TC-AVL-004 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-IAM-001 TC-IAM-006 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-MON-002 TC-PI-001 TC-PI-002 TC-PI-004 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Business Rules

11 rules, 9 to be proved before approval. A rule's product intent is derived from its origin: 2 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
For individual recipients, the current release selects console delivery and records it delivered when creating the notice.
origin: services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#4. Assumptions
no proof recorded yet
policyservicetest
services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#writes the console delivery delivered at once and records every other supported channel as not available until its milestone
02must prove
Proposed
Other supported personal channels are skipped until their e-mail, Slack, Teams or text milestone; Unsupported channels receive an unsupported resolution.
no proof recorded yet
policyservicetest
services-platform:modules/notifications/tests/unit/channel-resolution.spec.js#names the milestone of each channel that is not available
03must prove
Proposed
An installed adapter selects a channel only when its reachability check accepts the recipient; otherwise resolution retains the adapter's explanation.
no proof recorded yet
policyservicetest
services-platform:modules/notifications/tests/unit/channel-resolution.spec.js#skips a channel whose adapter says the person cannot be reached, with the adapter’s reason
04must prove
Proposed
Due chat and text deliveries use dedicated work queues; console and e-mail delivery do not use that queued-delivery mechanism.
no proof recorded yet
policyservice, databasetest
services-platform:modules/notifications/tests/unit/channel-resolution.spec.js#delivers chat and SMS as queued work, and the console and e-mail not
05must prove
Proposed
A send lock allows one consumer to act on a queued delivery; Redelivery of a final delivery does not send it again.
no proof recorded yet
invariantservice, databasetest
services-platform:modules/notifications/tests/integration/services/persistence/deliveries.integration.spec.js#lets only one of two consumers racing for the send win it
06must prove
Proposed
Transient failures retry with thirty-second exponential backoff, capped at thirty minutes and jittered by twenty percent; the eighth receive fails as attempts exhausted and dead-letters the item; permanent refusals fail immediately; thrown adapter errors enter transient recovery.
no proof recorded yet
calculationservicetest
services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#fails the delivery attempts_exhausted on the last receive and gives the item back at once to reach the dead-letter queue
07must prove
Proposed
Notice status is calculated from selected deliveries as routed, delivering, delivered, partially delivered, failed or no channel; Skipped, cancelled and expired deliveries are excluded, and superseded notices keep their status.
no proof recorded yet
calculationservicetest
services-platform:modules/notifications/tests/unit/instance-status.spec.js#is partially delivered when one delivered and another failed, none still active
08must prove
Proposed
Normal lifecycle transitions cannot reopen final deliveries; Skips require a reason, and rendered delivery payloads cannot exceed 8 KB; Explicit operator retry is a separate operation.
no proof recorded yet
invariantservice, databasetest
services-platform:modules/notifications/tests/integration/services/persistence/deliveries.integration.spec.js#never moves a delivery out of a final status
09must prove
Proposed
Provider reports append delivery events, deduplicate repeated event identities and retain only the latest fifty events without rejecting further reports.
no proof recorded yet
policyservice, databasetest
services-platform:modules/notifications/tests/integration/services/persistence/deliveries.integration.spec.js#keeps the newest fifty events of a delivery and drops the oldest, never refusing the report
10
Confirmed
Console, e-mail and text are native channels; Customer Slack and Microsoft Teams connections use the integration platform.
origin: services-platform:docs/proposals/notifications/23-decisions.md#D-02
policyservicedocumented
services-platform:docs/proposals/notifications/23-decisions.md#D-02. Slack and Teams are integrations; e-mail, in-app and SMS are native
11
Confirmed
Teams remains unavailable until Andrew resumes its milestone.
origin: services-platform:docs/proposals/notifications/23-decisions.md#D-09
policyservicedocumented
services-platform:docs/proposals/notifications/23-decisions.md#D-09. Microsoft: one Entra application, one Azure Bot, catalog distribution first

Scenarios

IdGivenWhenThenProvenance
01The notification type offers console and e-mail routes.Platform creates Jane's recipient notice.Console records delivery success while e-mail selection explains its pending milestone.test
services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#writes the console delivery delivered at once and records every other supported channel as not available until its milestone

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software