--- id: FAS-PFM-NOT-07 title: Association Communication Delivery feature: FEAT-PFM-NOT-07 product_area: platform module: notifications revision: 1 status: proposed product_intent: proposed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f capabilities: - CAP-PFM-NOT-016 - CAP-PFM-NOT-017 - CAP-PFM-NOT-018 - CAP-PFM-NOT-019 - CAP-PFM-NOT-020 scenarios: - id: FAS-PFM-NOT-07-01 title: Published compliance content yields protected recipient outcomes kind: behaviour exercises: - CAP-PFM-NOT-016 - CAP-PFM-NOT-017 - CAP-PFM-NOT-018 - CAP-PFM-NOT-020 relies_on: - ATS-PFM-NOT-016-08 - ATS-PFM-NOT-017-06 - ATS-PFM-NOT-018-13 - ATS-PFM-NOT-020-06 preconditions: >- Use an owner publication, an eligible recipient, a suppressed recipient and an environment-restricted address. steps: >- Commit the request, process its content and dispatch the accepted messages. expected: >- The request pins its publication and only the eligible recipient crosses the provider transport seam. negative: false data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: - TST-PFM-NOT-030 provenance: test source: - >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js - id: FAS-PFM-NOT-07-02 title: Bounce feedback changes the next request outcome kind: interaction exercises: - CAP-PFM-NOT-019 - CAP-PFM-NOT-020 relies_on: - ATS-PFM-NOT-019-01 - ATS-PFM-NOT-019-02 - ATS-PFM-NOT-020-01 - ATS-PFM-NOT-020-12 preconditions: Send a compliance message and retain provider correlation tags. steps: >- Record a permanent bounce, replay the feedback and submit another request to the same address. expected: >- The bounce has one retained event; the next request records a protected withholding outcome with no provider send. negative: false data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: - TST-PFM-NOT-030 provenance: test source: - >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js - id: FAS-PFM-NOT-07-03 title: 'Publication, acceptance and provider history retain distinct facts' kind: lifecycle exercises: - CAP-PFM-NOT-016 - CAP-PFM-NOT-017 - CAP-PFM-NOT-018 - CAP-PFM-NOT-019 relies_on: - ATS-PFM-NOT-016-14 - ATS-PFM-NOT-017-06 - ATS-PFM-NOT-018-13 - ATS-PFM-NOT-019-02 preconditions: >- A record owns no publication initially and an eligible contact is ready for compliance mail. steps: >- Submit before publication, publish corrected content, submit and send again, then report delivery and late deferral. expected: >- The first request stays blocked; the accepted request retains its version and submission, while late feedback does not reverse delivery. negative: false data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: - TST-PFM-NOT-030 provenance: test source: - >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js - id: FAS-PFM-NOT-07-04 title: 'Submission, message history and body access remain separate' kind: permission exercises: - CAP-PFM-NOT-017 - CAP-PFM-NOT-019 relies_on: - ATS-PFM-NOT-017-12 - ATS-PFM-NOT-019-05 - ATS-PFM-NOT-019-07 preconditions: >- Use a console caller, an authorized system caller and a message reader without sensitive content authority. steps: >- Attempt submission and then read request detail, messages and stored bodies under the relevant identities. expected: >- Only the system caller submits; workspace history and sensitive body access retain their separate checks. negative: true data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: [] provenance: proposed source: - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-017-ask-platform-to-send-an-association-e-mail.md#ATS-PFM-NOT-017-12 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-019-record-what-became-of-each-e-mail.md#ATS-PFM-NOT-019-05 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-019-record-what-became-of-each-e-mail.md#ATS-PFM-NOT-019-07 - id: FAS-PFM-NOT-07-05 title: Replayed queue work and feedback add no second send kind: regression exercises: - CAP-PFM-NOT-017 - CAP-PFM-NOT-018 - CAP-PFM-NOT-019 relies_on: - ATS-PFM-NOT-017-03 - ATS-PFM-NOT-018-02 - ATS-PFM-NOT-019-01 preconditions: >- Retain the accepted compliance request and a previously recorded delivery event. steps: >- Repeat publication, dispatcher processing, completed sending and delivery feedback. expected: >- The ordinary completed-message path keeps one submitted message and one copy of the provider event. negative: false data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: - TST-PFM-NOT-030 provenance: test source: - >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js evidence: - >- rhythm-v2-docs:specs/platform/notifications/planning/features/FEAT-PFM-NOT-07-association-e-mail.md - >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js - >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js - >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-017-ask-platform-to-send-an-association-e-mail.md#ATS-PFM-NOT-017-12 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-019-record-what-became-of-each-e-mail.md#ATS-PFM-NOT-019-05 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-019-record-what-became-of-each-e-mail.md#ATS-PFM-NOT-019-07 - >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js regression_record: - revision: 1 change: initial scenarios: - FAS-PFM-NOT-07-01 - FAS-PFM-NOT-07-02 - FAS-PFM-NOT-07-03 - FAS-PFM-NOT-07-04 - FAS-PFM-NOT-07-05 reason: >- Initial cumulative feature acceptance coverage from the pinned planning and design layers. --- # Association Communication Delivery: Feature Acceptance Suite ## What the Feature Must Do as a Whole This suite follows the feature from its initial inputs through the outcomes people inspect. Its cases combine capability results so that a change at one stage is checked against the later stages that depend on it. ## Interactions Between Capabilities Record a permanent bounce, replay the feedback and submit another request to the same address. The bounce has one retained event; the next request records a protected withholding outcome with no provider send. The feature cases retain their prerequisite scenario references. A component test alone does not establish execution of the complete feature chain. ## Regression Record | Revision | Change | Scenario | Why | |---|---|---|---| | 1 | initial | All initial cases | Establish cumulative feature coverage and preserve its dependencies for later revisions. |