---
id: ADR-MBR-STR-013
title: Publish Reparenting Inside the Placement Transaction
product_area: membership
module: structure
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Moves and relocated merge children persist reparent events before commit; creation, moves and merges also
  call after-commit telemetry, while closure and deletion contain no explicit telemetry calls.
constrains:
  - SVC-MBR-STR-structure
  - WF-MBR-STR-001
  - WF-MBR-STR-002
origin: >-
  services-membership:modules/events/services/publishing/publish-business-event.ts (architecture 07 §10:
  publishes change events, each with ids and effective dates); services-
  membership:docs/migrations/structure/README.md#What could not be done as specified, and why (the lifecycle
  event is telemetry)
alternatives:
  - option: Publish the business event only from the response path after commit.
    why_not: A post-commit request failure could lose the event for an already committed structural change.
  - option: Publish business events for all structural lifecycle changes.
    why_not: >-
      Additional merge and closure notifications require defined consumers and a product decision; they are
      not part of the examined event contract.
consequences:
  - The reparent outbox write commits or rolls back with its placement transaction.
  - No examined handler reacts to reparent events.
  - >-
    Connected applications needing merge or closure effects currently require a separately designed
    integration.
supersedes: []
evidence:
  - >-
    services-membership at 5994c270: modules/events/contracts/business-events.ts;
    modules/structure/services/tree/tree-edits.ts; aws/membership.change-events.ts
---

# Publish Reparenting Inside the Placement Transaction

## Context

Connected services may need to react when a unit changes parent. Structural telemetry and a durable published business event have different roles and guarantees.

## Decision

The existing business-event seam covers reparenting only. The registry determines configured recipients afterward, but this examination does not infer delivery bounds or receiver behavior from the outbox declaration.

## Alternatives Considered

Publish the business event only from the response path after commit. A post-commit request failure could lose the event for an already committed structural change. Publish business events for all structural lifecycle changes. Additional merge and closure notifications require defined consumers and a product decision; they are not part of the examined event contract.

## Consequences

The reparent outbox write commits or rolls back with its placement transaction. No examined handler reacts to reparent events. Connected applications needing merge or closure effects currently require a separately designed integration.