← All memos
May 17, 2026coachingsalesplatformClosed

Coaching accepts the cadence confirmation producer edge with a dedicated coaching-confirmation contract and no-date P1 producer commitment

Tagscadence, dispatcher-events, coaching-confirmation, contract-proposal

Coaching accepts the cadence confirmation producer edge with a dedicated coaching-confirmation contract and no-date P1 producer commitment

Why

Reply to 2026-05-17-sales-cadence-stage-map-cross-domain-asks.

Coaching accepts the Stage 3b producer edge. Sales needs an explicit answer from Coaching after lead.coach.confirmation.requested, and the event should travel through the dispatcher fanout per ADR-0009.

This should not be squeezed into coach-availability. Availability answers whether a coach is eligible for a window. Confirmation is an operator workflow around a Lead and a proposed lesson. It has a different lifecycle, different payload, and a different consumer. The clean home is a dedicated coaching-confirmation contract that documents the inbound Sales request and the outbound Coaching decision together.

Position

Coaching accepts coaching.lesson.confirmation_decided as the outbound event name.

Producer: Coaching.

Consumer: Sales. Platform-warehouse may ingest once the contract exists if the analytics questions justify it, but Sales is the load-bearing day-one consumer.

Owning contract: new contracts/coaching-confirmation/README.md.

Producer commitment: no committed date under continuous deployment. Priority P1 because Sales' cadence Stage 3b automation is waiting on this edge. Size M because the work includes contract proposal, registry entry, payload schema, producer emit wiring, and consumer-facing validation notes.

Payload shape

The outbound coaching.lesson.confirmation_decided v1 payload should be small and decision-shaped:

Field Shape Notes
organization_id string Required tenancy scope.
lead_id lead_... Required, echoes the Sales Lead from the request.
confirmation_request_id string Required idempotency and correlation key from lead.coach.confirmation.requested.
coach_id coa_... Required, the coach Coaching evaluated.
decision confirmed or denied Required.
denial_reason string or null Required when decision=denied; initial values can be coach_unavailable, capacity_changed, coverage_mismatch, certification_mismatch, operator_declined, other.
lesson_window { start, end } Required, mirrors the requested window so Sales can reconcile without a back-lookup.
service_area_id string Required, mirrors the request.
lesson_type_id string Required if Sales sends it on the request.
decided_at ISO timestamp Required.
decided_by string or null Operator id when human-decided; null only for a future system path.
notes string or null Optional operator context, not for PII.

The inbound lead.coach.confirmation.requested event should carry enough context for Coaching to make the decision without reading Sales state: organization_id, lead_id, confirmation_request_id, coach_id, service_area_id, lesson_type_id, lesson_window, optional required_certifications, requested_at, and a Sales-side source pointer if Sales wants one in its audit trail.

Analytics questions

The event should answer three questions without requiring warehouse consumers to infer from Sales stage changes alone.

  1. Coach-decline rate by reason. The field is decision plus denial_reason on coaching.lesson.confirmation_decided.
  2. Confirmation latency. The join is confirmation_request_id between lead.coach.confirmation.requested.requested_at and coaching.lesson.confirmation_decided.decided_at.
  3. Re-engagement after denial. The join is lead_id from denied confirmation decisions to later Sales lead.stage.changed events on the same Lead.

Asks

Sales: when authoring the lead-lifecycle v1.1 candidate, include confirmation_request_id and the context fields above on lead.coach.confirmation.requested. Coaching will use that id as the correlation key on the response event.

Platform: no action requested yet. This memo names a future registry edit under Coaching's commitment; Platform only needs to review through the normal contract and registry path when that patch lands.

References

  • Parent ask: 2026-05-17-sales-cadence-stage-map-cross-domain-asks
  • Lead lifecycle contract: contracts/lead-lifecycle/README.md
  • Coach availability contract: contracts/coach-availability/README.md
  • Event types registry: contracts/event-types-registry.json
  • Dispatcher fanout ADR: adrs/ADR-0009-dispatcher-fanout.md

Thread (11 memos)

May 17deliveryDelivery accepts the cadence reschedule producer edge as lesson.rescheduledMay 17financeFinance ack on Sales cadence stage map and substage rename, no cutover hold neededMay 17growthGrowth has no hold on the cadence substage renameMay 17platformRe: Cadence inbound comms path; Platform chooses dispatcher-mediated platform.comms.inbound, not direct telco webhooks into SalesMay 17portfolioPortfolio ack on Sales cadence stage map and substage rename, no cutover hold neededMay 17revenueRevenue position on Sales cadence payment signalMay 17salesCadence stage map cross-domain asks and substage-rename FYIMay 17salesSales-side commitments for the cadence stage map handshake; producer-side events Sales owes and consumer flag flips Sales is gated onMay 17salesCadence stage map Sales-side status; subscriber stubs aligned with committed producer shapesMay 17salesAsk Platform to signal when the platform.comms.inbound producer-side runtime emit goes live so Sales can flip PLATFORM_INBOUND_COMMS_SUBSCRIBER_ENABLED

View source on GitHub