Sales proposes ADR-0025, pre-handoff reservation creation is Person-keyed and Participant resolution belongs at Delivery hold-create
Why
Sales is blocked on a close-path rule that requires Delivery participant resolution before back-to-back Revenue reservations can be created. That is the wrong lifecycle boundary. The Sales operator is closing a Lead against a canonical person_id; they are not choosing or using a Delivery participant_id at that point.
The current mixed shape is spreading complexity: reservation-create requires participant_id, Sales single-close pre-resolves Participant, composite-close repeats Participant across every Revenue item, Revenue validates Participant before any Delivery hold exists, while Delivery hold-create already accepts participant_id or person_id. We should settle the architectural rule once instead of carrying the mismatch through every close workflow.
This reopens the 2026-05-22 participant-resolution thread at the architecture layer. Delivery and Revenue chose the pre-reservation participant ensure path there; Sales has now lived through the shape in the close orchestration and believes that decision should be superseded by a Person-keyed pre-handoff rule.
What
Sales has filed proposed ADR-0025, adrs/ADR-0025-pre-handoff-reservations-are-person-keyed.md.
The proposed decision is: Sales-originated pre-handoff reservation creation is Person-keyed. person_id plus organization_id is the required human context on Revenue reservation-create, both single-create and atomic multi-create. participant_id is optional context when Sales already has it, but it is not a precondition for creating the Revenue crr_.
Participant remains Delivery-owned and remains required for Delivery lesson operations. The change is only about where resolution happens: Delivery hold-create, not Sales before Revenue create. A Sales close can create Revenue reservation state with Person context, then call Delivery hold-create with the returned crr_ and the same Person context. Delivery ensures or reuses the (person_id, organization_id) Participant while creating the hold and returns it.
Asks
Platform, please review as contract owner for credit-reservation-lock and the identity boundary. If accepted, Platform owns the reservation-create sub-spec amendment that makes participant_id optional for Sales-originated create and atomic multi-create.
Revenue, please review the implementation impact on single-create and atomic multi-create validation, conflict reasons, persistence, and later attachment of Delivery-returned Participant or Lesson context.
Delivery, please confirm hold-create and atomic hold-create are the correct Participant resolution boundary for Sales-originated close orchestration, and that requests with person_id but no participant_id are supported intentionally rather than accidentally.
Coaching, please confirm eligibility-by-description remains Person-keyed with optional Participant context for Sales pre-handoff offers, or surface any hidden Participant dependency that needs a contract correction.
References
adrs/ADR-0025-pre-handoff-reservations-are-person-keyed.mdadrs/ADR-0003-person-canonical-entity.mdadrs/ADR-0006-credit-reservation-lock-state-machine.mdmemos/2026/2026-05-22-sales-close-orchestration-participant-resolution-blocker.mdmemos/2026/2026-05-22-delivery-participant-ensure-before-reservation.mdmemos/2026/2026-05-22-revenue-participant-resolution-position.mdcontracts/credit-reservation-lock/reservation-create-api.mdcontracts/credit-reservation-lock/README.md