Explain notification selection and delivery

Purpose

Recipients can understand the audience decision and the available delivery routes for a notice.

How It Works

A recipient opens the explanation for an inbox item. Platform returns recipient-rule and channel-resolution lists even when empty. Producer reasons take precedence over generic audience wording. Standard wording distinguishes direct selection, roles, permissions, responsibility holding and delegation. Skipped channels explain the unavailable milestone or adapter decision. The console combines those facts into a readable explanation. Older records can use client-generated explanations when server text is absent. Viewing the explanation leaves authorization for the underlying work unchanged.

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.

Channel processing supplies the delivery states and reasons inspected here.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

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

Outcomes: A notice explains recipient selection and recorded delivery outcomes.Stored explanations connect the notice to its originating event.
Surfaces: consoleapi
Intent sources: services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#3. How it works for the userservices-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S12

Controls

23 controls apply, from the corpus control catalogue.

TC-AVL-001 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-002 TC-IAM-004 TC-IAM-005 TC-LOG-001 TC-MON-001 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

Permissions

Key	Checked at	Scope
`platform.notifications.use`	api	record

Business Rules

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

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Notice detail includes explanatory lists for selected channels, skipped channels with reasons, recipient-selection rules and collapsed contributions, even when those lists are empty. no proof recorded yet	policy	api, service	test services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#reads one of its own with its why, and nobody else’s
`02`must prove Proposed	Recipient explanations distinguish direct selection, responsibility holding, delegation with an optional delegator name, responsibility fallback, role or permission holding, and HQ routing. no proof recorded yet	calculation	service	test services-platform:modules/notifications/tests/unit/audience-planner.spec.js#says a delegate covers the responsibility for the person they cover
`03`must prove Proposed	A nonblank producer-supplied audience reason replaces generic recipient wording; blank reasons retain the standard explanation. no proof recorded yet	policy	service	test services-platform:modules/notifications/tests/unit/audience-planner.spec.js#uses the producer’s own words for the rule when the entry carries a reason
`04`must prove Proposed	Unavailable-channel explanations name the future milestone, absence of support for the definition, or the adapter's reason; Delivery summaries use the same explanations. no proof recorded yet	policy	service	test services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#says the milestone of a channel not yet available on the delivery summary, as the resolution does
`05`must prove Proposed	The explanation sheet combines recipient reason and delivery destination into a readable sentence, lists unused-channel reasons and omits raw reason tokens. no proof recorded yet	policy	console	test react-console:components/notifications/__tests__/notifications.test.tsx#tells why in a sentence in the Why sheet
`06` Proposed	Older notices lacking server-supplied wording receive client-generated explanations for recipient rules and skipped channels.	policy	console	test react-console:lib/notifications/__tests__/model.test.ts#words each rule kind when there is no label
`07` Proposed	Viewing a notice or its explanation grants no additional permission to act.	policy	service	documented services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#D2. Does every console user get an inbox by default?

Scenarios

Id	Given	When	Then	Provenance
`01`	An administrator's assignment causes Jane to receive a Batch posting item.	Jane opens its recipient explanation.	The sheet identifies the administrator's assignment reason, console delivery and future e-mail availability.	test react-console:acceptance/notifications/playwright/journeys/history/NT-ACC-0101.spec.ts#NT-ACC-0101

Planning

Explain notification selection and delivery ​

Purpose ​

How It Works ​

Relationships ​