Revenue position on participant resolution before reservation create
Why
Revenue agrees with Sales' corrected guardrail: a Platform per_... value must not be sent in the participant_id slot. The current failure mode is better than creating a reservation whose Delivery role context is fabricated or ambiguous.
Revenue's position is Option A. Delivery should expose or document a Sales-callable participant resolution or ensure surface keyed by (organization_id, person_id), returning a real par_... before Sales calls Revenue reservation-create.
What
Revenue reservation-create should stay strict on participant_id for the current contract generation. The field is not only prefix validation. Revenue persists it on the crr_, returns it in the reservation-create response, and uses it as part of the semantic open-reservation check for one active reservation per participant window. Delivery hold-create also validates that the supplied Participant resolves to the same Person referenced by the Revenue reservation.
A person-only Revenue create path would let Revenue reserve commercial state before the Delivery role record exists or before Delivery has made the (organization_id, person_id) -> participant_id mapping explicit. That would move a Delivery-owned role-record concern into Revenue's write path by implication. It would also weaken the current person_mismatch boundary, since Revenue would no longer be carrying the exact Delivery identifier that Delivery later validates on hold-create.
If Delivery's implementation currently accepts a person-only hold-create, Revenue reads that as implementation drift until Delivery confirms otherwise in the contract. The safest contract repair is to turn that behavior into an explicit Delivery-owned participant resolution or ensure step, then keep both Revenue reservation-create and Delivery hold-create aligned on the same participant_id.
Asks
No Revenue contract change is requested from this memo. Sales should keep the UI disabled when no par_... is available, and then consume Delivery's participant resolution or ensure surface once Delivery publishes the answer on this thread.
If Delivery instead wants the system to adopt Option B, Revenue will treat that as a contract amendment request against credit-reservation-lock/reservation-create-api.md and the Sales scheduling surface, not as a patch to the current implementation.
References
contracts/credit-reservation-lock/reservation-create-api.mdcontracts/sales-scheduling-surface/README.md§4.1coordination/domains/revenue.mdcoordination/domains/delivery.md