---
id: TST-PFM-SEC-261
title: Workspace email strategy database and service checks
kind: integration
product_area: platform
module: security
revision: 2
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js
implements:
  - ATS-PFM-SEC-003-08
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 3
isolation: Use the prepared test database and suite-owned fixture rows; retain shared seed records.
assertion_evidence:
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#the
      e-mail sender a provisioning request asks for
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#a
      request that carries one
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#writes
      the tenant’s sender identity beside the tenant, in the submission’s own transaction
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#records
      the address its mail is to come from, and the domain being proved
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#leaves
      it pending, because the submission creates nothing in SES itself
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#names
      no SES identity and no DNS record yet: the participant finds those out
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#creates
      nothing in SES as it submits, so a request never waits on another service
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#a
      domain strategy that names no domain
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#proves
      the tenant’s id as the domain, the id being a hostname
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#leaves
      an address strategy without a domain, because it proves the address alone
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#a
      request that carries none
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#writes
      no sender identity, because the shared Rhythm sender is the answer for most tenants
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#a
      strategy the rules refuse
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses
      the domain strategy without a domain when the tenant has none of its own to lend it
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses
      a domain under the address strategy, which proves the one mailbox and nothing else
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses
      an address outside the domain, because an identity proved for one domain may not send as
      another
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses
      a domain that is a URL rather than a hostname
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses
      an address that is not an address, naming the field rather than echoing the value
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#refuses
      a strategy outside the closed list
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#creates
      no tenant at all when the strategy is refused: the request is rejected whole
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#creates
      nothing in SES when the strategy is refused
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#a
      tenant whose customer has published no DNS at all
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#opens
      the tenant anyway, which is what option A promises
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#leaves
      its sender identity pending, for the customer to finish in their own time
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#created
      the identities in SES on the way, so the customer has records to publish
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#ran
      the remote participants too, which is the premise that the whole plan ran
dependency_evidence: >-
  The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here.
  The suite controls Cognito, message delivery, workflow execution, remote service participants at
  the declared seams; those collaborators remain outside its live proof.
evidence:
  - >-
    services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js
  - >-
    Static review at the recorded source revision; executable results remain not-run and conformance
    remains not-verified.
binding_note: >-
  Each binding names the scenario to which this file contributes assertions. A binding is not a
  recorded pass and does not extend the file’s dependency boundary.
examiner: codex
examined_at: '2026-10-23'
final_text: OpenAI
dependency_review:
  provenance: test
  source: >-
    services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js
  explicit_no_doubles: false
  identified_double_boundaries:
    - Cognito
    - message delivery
    - workflow execution
    - remote service participants
---
# Workspace email strategy database and service checks

## Verification Boundary

The file exercises database or service behavior through the local integration harness. The assertion references identify the source checks for workspace email strategy.

## What This Suite Proves

The source assertions support the observations named in the bound scenarios. A scenario spanning multiple files must retain the other files’ contributions.

## What It Does Not Prove

This examination does not run the suite. Passing behavior, deployed conformance and the behavior of substituted dependencies require separate execution evidence.

## Real Dependencies and Test Doubles

The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The suite controls Cognito, message delivery, workflow execution, remote service participants at the declared seams; those collaborators remain outside its live proof.

## Must Not Be Doubled

Keep the queried database, applicable constraints and transaction boundaries real. Provider substitutes cannot establish delivery, cloud execution or cross-service recovery.