Skip to content

CAP-PFM-NOT-018Send association e-mail with retry and capacity control

Markdown

CAP-PFM-NOT-018

Send association e-mail with retry and capacity control

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

KindCapabilityProduct areaPlatformModuleStaff Notifications and Association CommunicationsRevision1

Read atservices-platform ad3f6a65react-console baf6dae3

The Formal Contract

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

Outcomes
Dispatch sends eligible association e-mail through capacity-controlled lanes.Ambiguous attempts can become eligible for another submission after the recovery interval.
Surfaces
jobapi
Intent sources
services-platform:docs/communications/architecture.md#2026-10-09 — Final acceptance

Controls

32 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-DAT-004 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-PRV-004 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
platform.communication-messages.updateapitenant

Business Rules

14 rules, 12 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.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Minute scheduling and post-commit nudges run oldest-first workspace dispatch under short claims; only pointers reach the queue; acknowledged rows are deleted, refused rows remain until claim expiry, concurrent claims stay exclusive and time exhaustion stops before the next workspace.
no proof recorded yet
policyservice, databasetest
02must prove
Proposed
Request processing handles one item at a time and skips final messages on redelivery; Potentially in-flight submissions wait through the ambiguity interval before the separate resubmission recovery applies.
origin: services-platform:docs/communications/architecture.md#2026-10-09 — Final acceptance
no proof recorded yet
invariantservice, databasetest
03must prove
Proposed
Throttling stops the remaining sends for that receive and retains their draft state until backoff retry; On receive eight, refused sends fail as exhausted, untouched messages are attempted and the item is dead-lettered.
no proof recorded yet
policyservicetest
services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#stops the rest of the request for this receive rather than pressing an unwell provider
04must prove
Proposed
Operator redrive reoffers exhausted messages only; provider-accepted and permanently refused messages remain final.
no proof recorded yet
lifecycleservicetest
05must prove
Proposed
A final pre-send check expires overdue messages without an attempt and withholds newly suppressed or reserved-domain recipients with a reason.
no proof recorded yet
validationservicetest
services-platform:modules/communications/tests/integration/services/persistence/messages.integration.spec.js#withholds a message whose recipient was suppressed since acceptance, state and reason written together
06must prove
Proposed
An uncertain submission waits through the ambiguity interval before its unknown attempt closes and a new claim can submit again; Provider send feedback can complete it during the wait.
no proof recorded yet
policyservicetest
services-platform:modules/communications/tests/integration/services/persistence/messages.integration.spec.js#claims it again once the ambiguity window has passed, the unknown attempt closed
07must prove
Proposed
Message-update permission permits cancellation only while a message is draft; Withheld, cancelled and submitted messages cannot be cancelled.
no proof recorded yet
lifecycleapi, servicetest
services-platform:modules/communications/tests/e2e/messages.e2e.spec.js#refuses cancelling a message that was withheld rather than drafted as 400
08must prove
Proposed
Purpose classification selects a distinct Marketing lane rather than trusting request input; Marketing traffic cannot enter the transactional queue or occupy its front positions.
no proof recorded yet
policyservicetest
services-platform:modules/communications/tests/integration/services/dispatch/marketing-lane.integration.spec.js#leaves the marketing row for the next run, never publishing it to the other lane
09must prove
Proposed
Transactional traffic reserves forty percent of account rate and can borrow unused Marketing capacity; Marketing is capped at sixty percent without borrowing; a lane without a previously read rate remains unlimited.
no proof recorded yet
calculationservice, databasetest
services-platform:modules/communications/tests/unit/services/dispatch/lane-bucket.spec.js#never lets the marketing lane borrow the transactional lane’s reserved tokens
10must prove
Proposed
Rate-budget waits remain inside the invocation when time permits, otherwise returning work to its lane with a delay that does not spend a retry; Completed sends are skipped on return.
no proof recorded yet
policyservicetest
services-platform:modules/communications/tests/integration/services/dispatch/marketing-lane.integration.spec.js#requeues the item rather than giving it back to the queue to spend a receive
11must prove
Proposed
Marketing pauses at ninety percent of the twenty-four-hour account quota and resumes below that threshold; Transactional processing continues.
no proof recorded yet
policyservicetest
12must prove
Proposed
Marketing requests require subscription classification and unsubscribe targets; other requests prohibit them; Delivery adds List-Unsubscribe and enables one-click unsubscribe for HTTPS targets.
no proof recorded yet
validationservicetest
services-platform:modules/communications/tests/integration/services/dispatch/marketing-lane.integration.spec.js#refuses a marketing request without a subscription type, with the library’s message
13
Proposed
Current lane scheduling does not guarantee equal workspace shares.
policyservicedocumented
14
Proposed
Provider submission includes the configuration set and correlation tags used to locate the message and workspace in feedback.
policyservicetest
services-platform:modules/communications/tests/integration/lifecycle/contact-role-compliance-communication.integration.spec.js#sends it with the configuration set and the tags that let feedback find the tenant and message

Scenarios

IdGivenWhenThenProvenance
01Marketing processes a forty-thousand-member newsletter when transactional compliance mail arrives.The two classified consumers use their lane budgets.Compliance uses reserved transactional capacity while Marketing waits for its own available tokens.inferred

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.