Delivery accepts the cadence reschedule producer edge as lesson.rescheduled
Why
Reply to 2026-05-17-sales-cadence-stage-map-cross-domain-asks.
Delivery accepts the Sales need for a dispatcher signal when a lesson's date changes after Stage 4 entry. Sales' lesson-date-keyed cron should not have to infer reschedules from a current-state poll, and Delivery is the right producer for the scheduling fact.
The event should join the existing Lesson lifecycle family as lesson.rescheduled, rather than minting a delivery.lesson.rescheduled name. The registry already uses unprefixed lesson.scheduled, lesson.attended, lesson.cancelled, and lesson.delivered for Delivery-produced lifecycle facts. The dispatcher envelope and registry carry producer ownership.
Position
Delivery accepts lesson.rescheduled as the event name.
Producer: Delivery.
Day-one consumer: Sales. Platform-warehouse may ingest once the contract and payload schema exist if the analytics use case justifies it.
Owning contract: contracts/lesson-lifecycle/README.md.
Producer commitment: no committed date under continuous deployment. Priority P1 because Sales' Stage 4 cadence path is waiting on a reschedule signal to keep its lesson date aligned after the initial close. Size M because the work includes a lesson-lifecycle minor version, registry edit, payload schema, producer emit wiring, and tests on the reschedule write path.
Payload shape
The v1 payload should be scheduling-shaped and PII-free:
| Field | Shape | Notes |
|---|---|---|
organization_id |
string | Required tenancy scope. |
lesson_id |
les_... |
Required. Sales should correlate to the Lesson returned by hold-create. |
reservation_lock_id |
lck_... or null |
Optional correlation for lock-backed lessons. |
reservation_id |
crr_... or null |
Optional Revenue reservation correlation when present. |
participant_id |
par_... |
Required when known on the Lesson. |
previous_window |
{ start, end } |
Required. |
new_window |
{ start, end } |
Required. Sales reads new_window.start as the updated lesson date. |
previous_coach_id |
coa_... or null |
Required as nullable. |
new_coach_id |
coa_... or null |
Required as nullable. |
previous_lesson_site_id |
lsi_... or null |
Required as nullable. |
new_lesson_site_id |
lsi_... or null |
Required as nullable. |
service_area_id |
sva_... or null |
Required as nullable. |
lesson_type_id |
lty_... |
Required when known on the Lesson. |
reschedule_reason |
string or null | Flexible operational reason, safe for consumers to treat as opaque. |
rescheduled_at |
ISO timestamp | Required. |
rescheduled_by |
string or null | Operator or system actor id, null only when unavailable. |
The event does not carry lead_id, Sales substage, or Sales cadence state. Sales owns the Lead correlation. Delivery owns the Lesson scheduling fact keyed by lesson_id.
Stage 4 entry verification
Sales' close-orchestration response already includes the lesson date on Stage 4 entry. The sales-scheduling-surface hold-create response in §4.1 returns window: { start, end }, and the delivery.lesson-hold.created event in §4.5 carries the same window. Sales can set Lead.lessonDate from the hold-create response immediately after the successful close, then use lesson.rescheduled to keep that value aligned if the lesson later moves.
References
- Parent ask:
2026-05-17-sales-cadence-stage-map-cross-domain-asks - Lesson lifecycle contract:
contracts/lesson-lifecycle/README.md - Sales scheduling surface contract:
contracts/sales-scheduling-surface/README.md - Event types registry:
contracts/event-types-registry.json - Dispatcher transport ADR:
adrs/ADR-0009-dispatcher-cross-process-transport.md