Sales close orchestration is blocked on Delivery participant resolution before reservation create

Why

Sales found a live close-path blocker while testing the Availability planner. The lead workbench has a canonical Platform person_id, but it does not have a Delivery-owned participant_id shaped as par_....

Sales has corrected its local guardrail so it no longer sends a per_... value in the participant_id slot. That prevents a misleading Revenue validation failure, but it also makes the booking path stop before reservation create with the operator-visible reason: "This lead needs a Delivery participant before creating the reservation."

This is the correct failure mode under the current contracts. Sales must not mint a Delivery Participant and must not infer a par_... from Platform Person identity. The unresolved question is which owner supplies the bridge from person_id to a bookable Delivery participant for Sales-originated first bookings.

What Sales observed

Delivery's sales-scheduling-surface contract requires participant_id on single hold-create and atomic multi-create. It also requires that the supplied Participant resolve to the same Person referenced by the Revenue reservation.

Revenue's reservation-create implementation currently validates participant_id as a Delivery participant identifier before Sales reaches the Delivery hold-create call. With only person_id available, Sales cannot pass Revenue validation and cannot reach the confirmation screen without either an actual Delivery participant or a contract-supported person-only path.

Delivery's current hold-create implementation appears to tolerate person_id as an input path for creating the hold when no participant is supplied. If that behavior is intentional, the coordination surface has drifted: Delivery can work from person_id, while Revenue reservation-create still requires participant_id.

Asks

Delivery and Revenue: please pick the contract direction for Sales-originated first bookings.

Option A: Delivery exposes or documents a Sales-callable participant resolution or ensure surface keyed by (organization_id, person_id), returning a real participant_id before Sales calls Revenue reservation-create. Under this option, the existing reservation-create requirement can stay strict.

Option B: Revenue amends reservation-create to accept person_id without participant_id for Sales-originated first bookings, and Delivery hold-create continues the person-only path until or unless it mints or resolves the Participant during hold creation. Under this option, participant_id remains present when known but is not a precondition for reservation create.

Sales does not have a preference as long as the boundary is explicit. The important invariant is that Sales cannot manufacture Delivery role records and should not pass Platform Person IDs through Delivery Participant fields.

Sales-side posture

Until the owning domains answer, Sales will keep the UI disabled when no par_... participant is present. That keeps bad requests out of Revenue and makes the missing cross-domain capability visible to the operator.

If the answer is Option A, Sales will consume the participant resolution surface before reservation create. If the answer is Option B, Sales will remove the participant precondition from its reservation-create payload and keep person_id as the identity anchor.

References

• contracts/sales-scheduling-surface/README.md §4.1 and §4.5, current hold-create and atomic multi-create request shapes
• contracts/credit-reservation-lock/reservation-create-api.md, Sales-callable Revenue reservation-create shape
• contracts/credit-reservation-lock/README.md §12.6 and §12.8, Sales-originated reservation create and composite reservation create
• coordination/domains/delivery.md, Delivery owns Participant (par_...)
• coordination/domains/sales.md, Sales resolves canonical Person through Platform identity and does not own role records