---
id: ADR-MBR-STR-002
title: Serialize Placement Changes and Rebuild Before Commit
product_area: membership
module: structure
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Creation, moves and merges lock the workspace tree and rebuild derived ancestry and depths before commit;
  closure and deletion use the same lock with narrower writes.
constrains:
  - DOM-MBR-STR-001
  - SVC-MBR-STR-structure
  - WF-MBR-STR-001
  - WF-MBR-STR-002
  - WF-MBR-STR-003
origin: >-
  services-membership:docs/migrations/structure/README.md#The move sequence as implemented (architecture 05
  §3; D-11, D-12)
alternatives:
  - option: Maintain only affected ancestry rows under fine-grained locks.
    why_not: >-
      Incremental maintenance would need a separate correctness argument for competing moves; the current
      implementation rebuilds from authoritative parents.
  - option: Refresh ancestry after the parent transaction commits.
    why_not: >-
      Derived reads and subsequent validation could observe a parent arrangement that the old ancestry does
      not describe.
consequences:
  - Ordinary placement edits commit reconciled ancestry and depth; bulk loads defer that reconciliation.
  - 'Structural edits wait behind one workspace lock, so tree size affects latency and throughput.'
  - Rebuild statements write differences rather than replacing every ancestry row.
supersedes: []
evidence:
  - >-
    services-membership at 5994c270: modules/structure/services/tree/tree-edits.ts;
    services/persistence/organizational-units.ts (rebuildUnitClosure); tests/integration/services/tree/tree-
    scale.integration.spec.ts
---

# Serialize Placement Changes and Rebuild Before Commit

## Context

Descendant reads and officer visibility depend on ancestry matching current parent references. Concurrent opposing moves must not validate against the same stale arrangement.

## Decision

The implemented placement flow uses a workspace tree lock and one transaction for validation, parent periods and rebuilding. Closure changes standing and deletion cleans up a removable unit without performing a whole-tree rebuild.

## Alternatives Considered

Maintain only affected ancestry rows under fine-grained locks. Incremental maintenance would need a separate correctness argument for competing moves; the current implementation rebuilds from authoritative parents. Refresh ancestry after the parent transaction commits. Derived reads and subsequent validation could observe a parent arrangement that the old ancestry does not describe.

## Consequences

Ordinary placement edits commit reconciled ancestry and depth; bulk loads defer that reconciliation. Structural edits wait behind one workspace lock, so tree size affects latency and throughput. Rebuild statements write differences rather than replacing every ancestry row.