--- id: CAP-PFM-TNL-015 title: Keep deletion decisions visible to staff feature: FEAT-PFM-TNL-05 product_area: platform module: tenant-lifecycle revision: 2 status: draft product_intent: proposed implementation_evidence: observed supersedes: [] source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 intent_sources: - 'services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5' - 'services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4' - 'services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D8' purpose: >- Deletion notices explain the request, changes and result, and required delivery states gate destruction. outcomes: - Recipients are the internal staff list and requester. - The request notice and latest one-day reminder gate destruction. - Failed delivery retains the waiting state. concepts: - CON-PFM-TNL-005 actors: - ACT-PFM-004 - ACT-PFM-039 - ACT-PFM-012 surfaces: - job preconditions: [] postconditions: [] permissions: [] rules: - id: BR-CAP-PFM-TNL-015-01 statement: >- Request creation schedules an immediate notice, a seven-day reminder for waits of at least eight days, and a one-day reminder that is immediate for waits shorter than two days. kind: calculation enforced_at: - service must_prove: true provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is due at once just below two days, so a short period still has the notice destruction waits for origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Reminder schedule (approved) - id: BR-CAP-PFM-TNL-015-02 statement: >- Notice obligations also accompany holds, releases, cancellation, destruction start and the final success or failure. kind: policy enforced_at: - service must_prove: true provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#owes an executing notice, so somebody is told the point of no return was passed origin: 'services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 (approved)' - id: BR-CAP-PFM-TNL-015-03 statement: >- Deletion notices target the environment’s staff list and the requester; the system sends no customer-facing deletion notice. kind: policy enforced_at: - service must_prove: true provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#tells the staff list and the requester, and nobody else origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4 (Andrew, 2026-10-09); §13 D8 (default in force) - id: BR-CAP-PFM-TNL-015-04 statement: >- The watcher sends due notices and waits for the next due time; unique kind-and-date slots deduplicate records without ensuring exactly-once message delivery. kind: invariant enforced_at: - service - database must_prove: true provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#slept until each notice was due rather than polling, and never for a fixed duration origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Delivery (approved) - id: BR-CAP-PFM-TNL-015-05 statement: >- Destruction requires the request notice and latest one-day reminder to be delivered or environment-suppressed; a failed gating notice keeps it waiting. kind: policy enforced_at: - service must_prove: true provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Notices that gate destruction (approved) - id: BR-CAP-PFM-TNL-015-06 statement: >- A notice retains delivery state, attempt count, error, recipients and delivery time as its sending history. kind: invariant enforced_at: - database must_prove: false provenance: test source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#counts every attempt, so a notice presented forty times reads differently from one presented once origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Record (approved) - id: BR-CAP-PFM-TNL-015-07 statement: >- An unconfigured staff list causes notice failure rather than silent omission and prevents destruction from beginning. kind: policy enforced_at: - service must_prove: true provenance: observed source: >- services-platform:modules/tenants/services/deletion/notices/notice-recipients.ts (header, An unset list is a failure) origin: >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4 (Andrew, 2026-10-09) - id: BR-CAP-PFM-TNL-015-08 statement: >- Accumulating notices never evicts the notice records required to authorize destruction. kind: invariant enforced_at: - service must_prove: false provenance: test source: >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#never drops the requested notice, which destruction waits for origin: none scenarios: - id: SC-CAP-PFM-TNL-015-01 given: The mail provider rejects the final gating reminder. when: The request reaches its eligibility date. then: >- Destruction remains waiting and subsequent checks continue rather than deleting silently. provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced edge_cases: [] constraints: [] depends_on: - CAP-PFM-TNL-013 related: - CAP-PFM-TNL-014 - CAP-PFM-TNL-016 - CAP-PFM-TNL-017 journeys: - JNY-PFM-TNL-004 open_questions: [] evidence: - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4 - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D8 - >- Inspected source: services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is due at once just below two days, so a short period still has the notice destruction waits for - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Reminder schedule (approved) - >- Inspected source: services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#owes an executing notice, so somebody is told the point of no return was passed - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 (approved) - >- Inspected source: services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#tells the staff list and the requester, and nobody else - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4 (Andrew, 2026-10-09); §13 D8 (default in force) - >- Inspected source: services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#slept until each notice was due rather than polling, and never for a fixed duration - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Delivery (approved) - >- Inspected source: services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Notices that gate destruction (approved) - >- Inspected source: services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#counts every attempt, so a notice presented forty times reads differently from one presented once - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Record (approved) - >- Inspected source: services-platform:modules/tenants/services/deletion/notices/notice-recipients.ts (header, An unset list is a failure) - >- Inspected source: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4 (Andrew, 2026-10-09) - >- Inspected source: services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#never drops the requested notice, which destruction waits for controls: [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-006, TC-LOG-002, TC-LOG-003, TC-LOG-005, TC-MON-002, TC-PI-001, TC-PI-002, TC-PI-005, TC-PRV-001, TC-PRV-002, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-VEN-001, TC-VEN-002, TC-VEN-003] --- # Keep deletion decisions visible to staff ## Purpose Deletion notices explain the request, changes and result, and required delivery states gate destruction. ## How It Works Request creation establishes the notice obligations for the waiting period. The schedule job sends each due notice and waits for the next due instant. Holds, releases and cancellation add their own notices. Destruction start and completion or failure are announced too. The recipient list combines the environment’s internal staff list and requester. An absent staff list is a delivery problem rather than permission to skip notification. The request notice and latest one-day reminder must be delivered or environment-suppressed before destruction. Failed gating notices keep the schedule waiting. Notice records retain attempts and errors, while record deduplication does not guarantee exactly-once message delivery. ## Relationships - Schedule deliberate workspace deletion: Its result establishes the state or declared resources needed by this operation. - Pause or cancel deletion while preservation remains possible: The capabilities share the workspace’s recorded lifecycle decision. - Revalidate the irreversible deletion decision: The capabilities share the workspace’s recorded lifecycle decision. - Remove declared workspace resources and verify the result: Its batches and inventory determine the removal result.