--- id: CON-PFM-NOT-005 name: Association Communication feature: FEAT-PFM-NOT-07 product_area: platform module: notifications revision: 1 status: draft product_intent: proposed implementation_evidence: observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A workflow e-mail submission and its recipient messages, including rendering, submission attempts, provider feedback, recipient protection and sender choice. owned_by: MOD-PFM-NOT synonyms: - association e-mail - communication request - message not_to_be_confused_with: - A staff notification - >- Marketing owns campaign planning and uses communication delivery to send its content. facets: - name: Submission meaning: >- The request identifies purpose, template owner or version, source records, recipients and idempotency key. used_for: Link workflow submission to durable message history. - name: Acceptance decision meaning: >- Accepted, configuration-blocked, suppressed and invalid outcomes retain reasons. used_for: Explain why a submission produced mail or stopped. - name: Object and queue pointer meaning: >- Request objects have a thirty-day lifecycle; committed queue pointers make them dispatchable. used_for: Keep large content out of queue entries and relational rows. - name: Recipient message meaning: >- A rendered message retains rendering kind, pinned version, dispatch state and provider delivery state. used_for: Trace the distinct outcomes for each recipient. - name: Withholding explanation meaning: >- Suppression, reserved domains and environment policy explain protected recipients. used_for: Distinguish deliberate withholding from processing failure. - name: Submission attempt meaning: Each provider handoff has an attempt record and result. used_for: >- Investigate retries and ambiguous submissions without promising exactly-once delivery. - name: Provider feedback meaning: >- Send, delivery, deferral, bounce, complaint, rejection, open and click reports are deduplicated. used_for: Record provider outcomes separately from dispatch. - name: Activity signals meaning: >- Open and click counters distinguish automated activity from likely-human signals. used_for: Show engagement without equating it with confirmed reading. - name: Traffic classification meaning: >- The purpose selects transactional or Marketing delivery; Marketing includes subscription and unsubscribe metadata. used_for: Reserve transactional capacity and support unsubscribe headers. - name: Documents and copies meaning: >- Caller-rendered messages can carry bounded attachments and optional copy addresses. used_for: Send workflow documents while checking copies like recipients. - name: Address suppression meaning: >- Permanent bounce, complaint or staff action creates a workspace do-not-send entry released only with a reason. used_for: Protect recipients and sender reputation. - name: Demonstration addressing meaning: Reserved domains cannot receive delivery in any environment. used_for: Prevent sample addresses from becoming provider sends. - name: Nonproduction policy meaning: >- Test mailboxes and explicitly permitted addresses or domains are the only nonproduction destinations. used_for: >- Constrain test delivery without claiming that all permitted recipients are synthetic. - name: Association sender meaning: >- A workspace setting records address or domain strategy, DNS instructions and provider verification. used_for: Use association identity when it can send. - name: Fallback address meaning: >- Rhythm's shared sender remains available until workspace identity is verified. used_for: Continue eligible delivery while DNS verification is pending. - name: Account capacity meaning: >- Separate lane rate budgets and a Marketing quota pause reserve capacity for transactional traffic. used_for: Control bulk sending without guaranteeing workspace fairness. - name: Feedback correlation meaning: >- Provider configuration and message tags identify the workspace and message in reports. used_for: Associate asynchronous feedback with retained history. relationships: - to: CON-PFM-NOT-004 statement: >- Platform-rendered recipient messages retain the published template version selected for them. provenance: test source: >- services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#accepts the request with the owner’s published version pinned - to: CON-PFM-NOT-003 statement: >- Association mail uses committed pointers for workflow recipients, alongside the separate staff notification model. provenance: documented source: >- services-platform:docs/communications/architecture.md#18. Rework 2026-10-10: queue pointers, S3 for request data and bodies, SQS owns retries lifecycle: - state: received meaning: The producer has committed work and received a submission receipt. how_it_changes: Commit makes the stored request pointer dispatchable. - state: accepted meaning: >- Recipient messages have been rendered and classified as queued or withheld. how_it_changes: The consumer evaluates and accepts the request. - state: 'blocked, suppressed or invalid' meaning: A recorded acceptance reason prevents any message from sending. how_it_changes: 'Configuration, recipient policy or contract validation prevents delivery.' - state: message sent meaning: Provider submission is recorded independently of later delivery feedback. how_it_changes: Sending records the provider handoff and its attempt result. - state: 'message delivered, bounced or complained about' meaning: Provider feedback identifies delivery or a negative recipient outcome. how_it_changes: Correlated feedback updates the message delivery state. acted_on_by: - CAP-PFM-NOT-017 - CAP-PFM-NOT-018 - CAP-PFM-NOT-019 - CAP-PFM-NOT-020 visible_to: - ACT-PFM-028 - ACT-PFM-030 - ACT-PFM-031 evidence: - >- Pinned evidence inventory 1: services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js - >- Pinned evidence inventory 2: services-platform:docs/communications/architecture.md supersedes: - CON-PFM-NOT-006 intent_sources: - >- services-platform:docs/communications/architecture.md#2026-10-09 — Final acceptance --- # Association Communication ## What It Is An association communication spans a workflow's request and the messages produced for individual recipients. It carries the association's e-mail to members or contacts rather than organizing staff inbox work. The request explains the workflow intent; each message explains rendering, withholding, submission and the provider's later reports. Protection and capacity belong to this same outcome. A communication cannot be understood only as a body handed to a mail provider. The sender needs to be usable, recipients must pass policy, retries must respect uncertain submissions, and Marketing traffic must not consume the transactional lane's reserved capacity. These are facets of the communication rather than another independent product concept. ## What It Is Not A request receipt is not provider acceptance, and provider acceptance is not evidence of a person reading an e-mail. Dispatch, delivery and engagement remain separate facts. A transactional purpose can ignore general contact opt-out while still respecting address suppression and environment protection. ## How It Is Used A macroservice stores request content and inserts its queue pointer in the business transaction. Processing pins the appropriate content and creates one message identity per recipient. Final pre-send checks can still withhold or expire accepted work. Provider feedback updates message history asynchronously. Staff inspect outcomes through read permissions, while body access requires an additional sensitive permission. ## Its Facets **Submission.** The request identifies purpose, template owner or version, source records, recipients and idempotency key. Link workflow submission to durable message history. **Acceptance decision.** Accepted, configuration-blocked, suppressed and invalid outcomes retain reasons. Explain why a submission produced mail or stopped. **Object and queue pointer.** Request objects have a thirty-day lifecycle; committed queue pointers make them dispatchable. Keep large content out of queue entries and relational rows. **Recipient message.** A rendered message retains rendering kind, pinned version, dispatch state and provider delivery state. Trace the distinct outcomes for each recipient. **Withholding explanation.** Suppression, reserved domains and environment policy explain protected recipients. Distinguish deliberate withholding from processing failure. **Submission attempt.** Each provider handoff has an attempt record and result. Investigate retries and ambiguous submissions without promising exactly-once delivery. **Provider feedback.** Send, delivery, deferral, bounce, complaint, rejection, open and click reports are deduplicated. Record provider outcomes separately from dispatch. **Activity signals.** Open and click counters distinguish automated activity from likely-human signals. Show engagement without equating it with confirmed reading. **Traffic classification.** The purpose selects transactional or Marketing delivery; Marketing includes subscription and unsubscribe metadata. Reserve transactional capacity and support unsubscribe headers. **Documents and copies.** Caller-rendered messages can carry bounded attachments and optional copy addresses. Send workflow documents while checking copies like recipients. **Address suppression.** Permanent bounce, complaint or staff action creates a workspace do-not-send entry released only with a reason. Protect recipients and sender reputation. **Demonstration addressing.** Reserved domains cannot receive delivery in any environment. Prevent sample addresses from becoming provider sends. **Nonproduction policy.** Test mailboxes and explicitly permitted addresses or domains are the only nonproduction destinations. Constrain test delivery without claiming that all permitted recipients are synthetic. **Association sender.** A workspace setting records address or domain strategy, DNS instructions and provider verification. Use association identity when it can send. **Fallback address.** Rhythm's shared sender remains available until workspace identity is verified. Continue eligible delivery while DNS verification is pending. **Account capacity.** Separate lane rate budgets and a Marketing quota pause reserve capacity for transactional traffic. Control bulk sending without guaranteeing workspace fairness. **Feedback correlation.** Provider configuration and message tags identify the workspace and message in reports. Associate asynchronous feedback with retained history. ## How It Relates Platform-rendered communications pin association template versions; caller-rendered purposes use supplied content instead. Notification submissions share the idea of durable queue publication but serve staff inbox outcomes. Recipient protection and sender verification remain communication facets, which is why the former safeguards concept is superseded. ## What It Could Become The product should agree on ambiguous-submission recovery, fair workspace capacity and the ownership of adopted sender identities. It should also confirm the later caller-rendered and Marketing extensions and define retention maintenance. Design must keep provider signals distinct from promises about human receipt or reading.