Phase 5b — Email Module

Phase 5b delivered the backend ShopAccess/Email module in the operations repository: per-tenant Postmark provisioning, transactional send with a fixed From, webhook ingestion, suppression, drift detection, and the operator lifecycle. This page is the project record; the durable design has been promoted to current-system (see below).

Status

• Implementation: complete. Landed on operations PR #191 (consolidated S01–S11), full build green, merged. Pre-go-live design reconciliation (the design corrections) applied on the same PR.
• Infrastructure: ready. Phase 4 per-partition exports verified live in all four partitions (dev, stage, demo, prod) — the …-API-PartitionMailZoneName / …ZoneId / …Email* exports the module consumes are present, and the zone-name values are {partition}.ardamails.com as expected.
• Open follow-ups: api-test Bruno examples to drop the removed fromLocalPart field; PDEV-903 (multi-From via Postmark Domains).

Durable design (promoted to current-system)

The module’s design now lives in the permanent docs, not in this roadmap record:

• Functional design → current-system/functional/shop-access/email/ — overview, domain model, lifecycle, provisioning & sending, webhook ingestion, API reference.
• Runtime substrate → current-system/runtime/partition-mail-topology.md — the per-partition mail surface and how the module consumes its CFN exports.
• Operating the module → current-system/oam/postmark-service/module-operator-runbook.md — drift assertions, lock/unlock, verification, suppression.
• Decisions → decisions/record/email-module-decisions.md — partition-qualified domain, fixed From, dropped SPF verification.
• Reusable practice → process/…/parametric-infrastructure-values.md.

The full design exploration (formal models, per-story plans, the verbatim working design) remains in the workbooks notebook (notebooks/email-integration/5b/) as the source-of-process; only the curated product design was promoted.

OAM telemetry families (project reference)

For completeness, the module’s structured-log / Sentry telemetry families (operator-facing summary in the module runbook):

Family	Covers
email.configuration.lifecycle.*	provisioning, verification, lock/unlock transitions; a gauge for configurations per operational state
email.send.*	send attempts, outcomes, transient vs permanent failures, configuration-failure entries
email.webhook.*	inbound events by type, rejections (auth_mismatch), status projections, INCONSISTENT
email.drift.*	the five drift-assertion tags (partition carried by the Sentry environment dimension, not a context field)
email.material_registry.refresh.*	encryption-key registry reloads (added / parse-failed)