---
id: TST-PFM-NOT-059
title: workspace sender address
kind: integration
product_area: platform
module: notifications
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js
implements:
  - ATS-PFM-NOT-020-07
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: >-
  Suite-owned records in the prepared integration workspaces; seeded workspace
  identities remain shared fixtures.
assertion_bindings:
  - scenario: ATS-PFM-NOT-020-07
    suite: TST-PFM-NOT-059
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js#sends
        from the association’s own address
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js#sends
        from the shared Rhythm sender, so the tenant’s mail never waits for the
        customer
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js#sends
        from the shared Rhythm sender rather than from an address SES would
        refuse
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js#keeps
        answering the same thing for the minute it is held, although the setting
        has changed underneath
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js#asks
        again once the minute is up, so a customer who published sees it take
        effect
evidence:
  - >-
    services-platform:modules/communications/tests/integration/services/sender-identity/tenant-sender-address.integration.spec.js
  - The file and referenced assertion titles exist at the pinned commit.
dependency_evidence:
  - >-
    Real: PostgreSQL (the prepared integration database, row-level security on),
    the whole deployed send path — submission,
  - >-
    the dispatcher's claim, the consumer, `sendMessage` and the sender choice.
    Doubled: SES at the transport seam, the object
  - >-
    store, the send queue and the dispatcher's nudge, as the whole tier doubles
    them. Never doubled: the database, the
---

# workspace sender address

## Verification Boundary

This suite exercises the local services and prepared PostgreSQL database. API lifecycle cases use signed test contexts through the real route handler; they do not invoke the deployed gateway.

## What This Suite Proves

Its cases exercise use shared sending until workspace verification.

The registered scenario bindings identify the assertions this executable file contributes. They retain individual test references so that a composite scenario does not become a claim of complete execution by one file.

## What It Does Not Prove

Local outcomes do not prove deployed queues, external provider acceptance, production credentials or complete browser behavior. No fresh execution or conformance result is claimed.

## Real Dependencies and Test Doubles

The communication fixtures use real PostgreSQL and module logic. Shared support records queue and transport calls and stores objects in memory; sender provisioning substitutes a provider identity store. Signed API contexts replace the authorizer key in API suites.

## Must Not Be Doubled

Database constraints, workspace policy, state guards and the service operation under test must remain real. Recording a provider or queue call must not replace the submission, claim or outcome logic being checked.