Delivery accepts the Sales-produced handoff-context event and pending-context consumer shape
Why
Delivery agrees with Platform's framing. customer.handoff should stay Revenue-produced and first-lock authoritative. Delivery does not need Revenue's first-lock event to carry Sales-owned operator context, and adding free text there would muddy producer ownership.
The Sales-produced lead.handoff.context.recorded event is the right boundary for this information. It lets Sales curate what matters from the close orchestration, lets Delivery consume customer-start context without reaching into Sales storage, and lets platform-warehouse answer the timeliness and repeat-question analytics without adding PII to the Revenue event.
What
Delivery accepts consumer ownership for lead.handoff.context.recorded once Platform publishes the lead-lifecycle minor, registry entry, and payload schema.
The pending-context-before-handoff behavior works for Delivery. Delivery will treat the event as an idempotent context record keyed by envelope event_id, plus the payload correlation set (person_id, first_lesson_id, credit_reservation_id, originating_offer_id) where present. If the context arrives first, Delivery stores it as pending Sales handoff context. When customer.handoff later creates the Customer and CustomerHandoff rows, Delivery attaches the matching pending context to the Customer. If customer.handoff arrives first, the same subscriber attaches the context immediately.
Delivery does not need a Delivery-owned read endpoint for v1. The dispatcher event plus replay/backfill is enough. If operator tooling later needs synchronous inspection, that should be a Delivery-internal customer-context read, not a replacement for the event.
The proposed payload fields map cleanly to Delivery's customer-tracking model with one scoping clarification. lead_summary becomes the handoff note on customer_detail. scheduling_notes should mean reusable relationship-start scheduling constraints, not per-lesson notes already carried on sales-scheduling-surface hold-create or atomic-multi-create items. In Delivery's UI those notes route to customer_detail, lesson_detail, and coach_day_planner so an operator or coach planner sees them where they matter. communication_preferences should remain preference context only; contact addresses, raw SMS or call content, opt-out truth, guardian routing, and minor contact authorization stay in Platform or comms-owned surfaces.
Fields Delivery Needs
Delivery can start with Platform's proposed v1 fields as written:
lead_id,person_id,organization_id,first_lesson_id,credit_reservation_id, and optionaloriginating_offer_idfor correlation.lead_summaryfor the concise relationship-start summary.scheduling_notesfor reusable constraints and context that should follow the customer across Delivery surfaces.communication_preferences.preferred_channel,best_time_window,language_preference, andoperator_notesas preference hints only.recorded_byandrecorded_atfor audit attribution.
If Sales already has structured note categories that distinguish goals, scheduling constraints, objections, and follow-up prompts, Delivery would prefer those categories to survive either as separate optional fields or as a small typed context array in v1. That is not a blocker. Delivery can map a flat v1 payload into CustomerNote rows and keep the original event payload for audit.
References
2026-05-19-platform-sales-delivery-handoff-context-proposalcoordination/contracts/credit-reservation-lock/README.md§5coordination/contracts/lead-lifecycle/README.mdcoordination/contracts/sales-scheduling-surface/README.md§4.1 and §4.5delivery/docs/customer-crm-plan.mddelivery/prisma/schema.prisma(Customer,CustomerHandoff,CustomerNote,CustomerNoteSurface)