---
id: WF-ACC-BKS-010
title: Purge Workspace Accounting Records in Batches
trigger: >-
  Platform asks an Accounting participant to purge a workspace recorded as
  deleting.
product_area: accounting
module: books
revision: 1
status: draft
design_intent: proposed
implementation_evidence: observed
inference: []
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
implements:
  - CAP-ACC-BKS-019
moves:
  - STATE-ACC-BKS-005
crosses: []
idempotency: >-
  Each call examines the participant’s declared order from the beginning and
  removes one batch from the first nonempty table. Repetition continues from
  remaining rows without a saved purge position.
concurrency: >-
  The deployed lifecycle Lambda has reserved concurrency one. Each purge batch
  uses its own transaction and uncached workspace-state check; this does not
  coordinate undeclared alternative writers.
hops:
  - 'n': 1
    actor_or_service: Platform deletion job
    action: >-
      Serve the requested participant purge step; Platform sequences dependent
      participants before configuration and repeats continuing outcomes.
    anchor: >-
      services-accounting:modules/maintenance/services/participants/registry.ts:accountingTenantLifecycleParticipants
    seam: sync
    on_failure: >-
      Platform can repeat a failed call; already committed earlier batches are
      not restored.
    left_inconsistent: Earlier successful batches can leave the workspace partially erased.
    observer: Platform's lifecycle run
    provenance: test
    source: >-
      services-accounting:modules/maintenance/tests/integration/services/participants/configuration-participant.integration.spec.js#resumes
      to done when it is called again
  - 'n': 2
    actor_or_service: Accounting lifecycle function
    action: >-
      Validate the operation and bounded batch request, then enter the named
      workspace.
    anchor: >-
      services-accounting:modules/maintenance/services/lifecycle/tenant-lifecycle-operations.ts:runTenantLifecycleOperation
    seam: sync
    on_failure: Return a named request failure before attempting removal.
    left_inconsistent: This call has removed nothing.
    observer: Platform's lifecycle run
    provenance: test
    source: >-
      services-accounting:modules/maintenance/tests/unit/lifecycle/tenant-lifecycle-operations.spec.js#refuses
      a reset, which Accounting does not serve
  - 'n': 3
    actor_or_service: Purge loop
    action: >-
      Open a capture-suppressed batch transaction and verify fresh deleting
      standing.
    anchor: >-
      services-accounting:modules/maintenance/services/participants/purge-batches.ts:purgeNextBatch
    seam: sync
    on_failure: >-
      Refuse absent or nondeleting standing, including a state changed after
      earlier purge batches.
    left_inconsistent: No additional records are removed by the refused transaction.
    observer: Platform's lifecycle run
    provenance: test
    source: >-
      services-accounting:modules/maintenance/tests/integration/services/participants/configuration-participant.integration.spec.js#refuses
      a tenant that is not being deleted
  - 'n': 4
    actor_or_service: Purge loop and database
    action: >-
      Remove a bounded batch from the first nonempty declared table; owner
      functions handle append-only records under the same deletion checks.
    anchor: >-
      services-accounting:modules/maintenance/services/persistence/tenant-purges.ts:deleteTenantRows
    seam: sync
    on_failure: Roll back the current batch on a delete or owner-function failure.
    left_inconsistent: Prior batches remain removed; this batch does not partially commit.
    observer: The orchestration run’s per-table removal counts
    provenance: test
    source: >-
      services-accounting:modules/maintenance/tests/integration/services/participants/configuration-participant.integration.spec.js#leaves
      the other tenant’s rows exactly as they were, table for table
  - 'n': 5
    actor_or_service: Configuration participant
    action: >-
      Return continuing or complete status with removal detail; inventory
      reports remaining counts.
    anchor: >-
      services-accounting:modules/maintenance/services/participants/purge-batches.ts:countRemainingRows
    seam: sync
    on_failure: >-
      A reporting failure gives Platform no new successful continuation
      response.
    left_inconsistent: >-
      Stored removal effects must be inferred from remaining rows on the next
      call.
    observer: Platform's lifecycle run
    provenance: observed
    source: >-
      services-accounting:modules/maintenance/services/participants/configuration-participant.ts:accountingConfigurationParticipant
branches:
  - condition: Change workspace state after partial erasure
    path: >-
      A later batch refuses further removal when deleting standing is gone;
      prior removals remain permanent.
waits: []
evidence:
  - >-
    services-accounting at f47cb263:
    modules/maintenance/services/participants/purge-batches.ts,
    configuration-participant.ts, registry.ts;
    services/persistence/tenant-purges.ts, tenants.ts
  - >-
    services-accounting at f47cb263:
    modules/maintenance/tests/integration/db/purge-order.integration.spec.js,
    declaration-completeness.integration.spec.js
controls: [TC-IAM-001, TC-IAM-002, TC-IAM-004, TC-IAM-005, TC-IAM-006, TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-AZ-005, TC-AZ-006, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-DAT-001, TC-DAT-004, TC-LOG-001, TC-LOG-002, TC-LOG-003, TC-LOG-004, TC-LOG-005, TC-PI-001, TC-PI-003, TC-PI-005]
---

# Purge Workspace Accounting Records in Batches

## What It Does

Purge removes the selected workspace’s Accounting records through small resumable calls. Participant dependencies and local child-first orders keep referenced configuration until dependent work is removed. Platform owns the continuing loop; Accounting performs a bounded step and reports its result.

## The Flow

```mermaid
flowchart TD
  h0["Serve the requested participant purge step; Platform sequences dependent participants before configuration and repeats continuing outcomes."]
  h1["Validate the operation and bounded batch request, then enter the named workspace."]
  h0 --> h1
  h2["Open a capture-suppressed batch transaction and verify fresh deleting standing."]
  h1 --> h2
  h3["Remove a bounded batch from the first nonempty declared table; owner functions handle append-only records under the same deletion checks."]
  h2 --> h3
  h4["Return continuing or complete status with removal detail; inventory reports remaining counts."]
  h3 --> h4
```

## When Something Fails

A failed batch rolls back itself. Later calls rediscover progress from remaining rows, so no cursor restoration is required. Each batch checks current deleting standing without the availability cache. If that standing changes after partial erasure, subsequent calls stop, while earlier deletion remains permanent. Declaration and purge-order tests check coverage against database references; bindings alone do not establish a production execution.

## Open Design Questions

The configuration participant still declares records owned by Products and Batches. The ownership of those lifecycle declarations needs to be considered alongside each module’s own dataset and reader declarations.