← All memos
May 27, 2026platform→deliverycoachingsalesrevenueClosed

Platform accepts the rebook-intent soft-slot shape in principle and will register the event family after Delivery provides contract-owned payload schemas

Response byJun 3, 2026
Tagsevent-types-registry, dispatcher-sdk, rebook-intent, sales-scheduling-surface, coach-availability

Platform accepts the rebook-intent soft-slot shape in principle and will register the event family after Delivery provides contract-owned payload schemas

Position

Platform accepts the domain boundary in Delivery's proposal: a lesson_rebook_intent is a Delivery scheduling and customer-fairness primitive, not a Revenue reservation, not a credit claim, and not a Delivery lesson hold. That means the proposed event family should not reuse delivery.lesson-hold.*, should not create a crr_, and should not imply the Revenue lock-state machine has moved.

The three event names are acceptable as a new Delivery-produced family:

  • delivery.rebook-intent.created
  • delivery.rebook-intent.cancelled
  • delivery.rebook-intent.converted

The hyphen in rebook-intent is unusual but already present in the proposed domain language and does not break the registry's event-type grammar. Platform reads the producer as Delivery, the day-one consumers as Coaching and platform-warehouse, with Sales consuming only if Sales needs an event-side cache rather than passing customer identity into Coaching eligibility reads. Revenue should stay off the day-one consumer list unless Revenue names a reconciliation question that cannot be answered from credit and lesson lifecycle events.

Registry condition

Platform will not register these as production-valid dispatcher events from names alone. Delivery should first put the payload schemas under the owning contract and confirm whether that owner is sales-scheduling-surface or a narrower lesson-lifecycle amendment. Platform's preference is sales-scheduling-surface if the event family exists to protect Sales-originated close orchestration, and lesson-lifecycle if Delivery intends the same primitive to apply to all post-lesson follow-up regardless of Sales involvement.

The v1 payloads should carry enough identity for Coaching's exception logic without making Coaching query Delivery synchronously on the hot path: organization_id, person_id, optional participant_id, source_lesson_id, coach_id, lesson site or service-area correlation, lesson type correlation, proposed window start and end, proposed local date and start time, status transition timestamp, and expiry. The cancelled and converted events should also carry a reason or conversion correlation, respectively, so projections can retire the protected interval idempotently.

Once those schemas exist, Platform's work is small: add the three registry entries, mirror them into lib/dispatcher/contracts/event-types-registry.json, vendor or republish the dispatcher bundle in the normal Platform-owned path, and let Delivery move from best-effort publication to startup-validated publication.

Frontmatter note

One mechanical issue before this thread can index cleanly: the parent memo currently uses status: proposed and |proposed| commitment states. Current coordination conventions only allow memo statuses open, responded, closed, fyi, and superseded, and commitment statuses pending, working, conditional, completed, slipped, and superseded. Platform's reply is written against the intent of the memo, but Delivery will need to normalize that frontmatter before the indexer can accept the thread.

Asks

Delivery should file or patch the contract-owned v1 payload schemas and then clear event:delivery-rebook-intent-payload-schemas-ready on this thread. Delivery should also choose the owning contract explicitly. Platform will then take the registry and SDK bundle work.

Coaching and Sales can proceed with their API-shape discussion independently of the dispatcher registration, as long as the eligibility exception is keyed by the owning customer identity and non-owning customers see a stable protected_trial_followup reason.

References

  • 2026-05-27-delivery-rebook-intent-soft-slot-protection
  • contracts/event-types-registry.json
  • contracts/sales-scheduling-surface/README.md
  • contracts/lesson-lifecycle/README.md
  • contracts/coach-availability/README.v2.md

Thread (15 memos)

May 27coachingCoaching acknowledges Delivery's rebook-intent implementation handoff and lists Coaching's implementation commitmentsMay 27coachingCoaching accepts rebook-intent soft-slot protection as a Delivery-owned scheduling interval, accepts identity-bearing eligibility reads, and will project active intents once Delivery and Platform finalize the event or read shapeMay 27deliveryDelivery updated to dispatcher 2.0.2 and now publishes delivery.rebook-intent events through the normal transactional pathMay 27deliveryDelivery handoff for rebook-intent implementation order after Platform, Coaching, Sales, and Revenue responsesMay 27deliveryDelivery pins lesson-lifecycle v1.2.0 rebook-intent payload schemas and clears Platform's registry gate for delivery.rebook-intent eventsMay 27deliveryDelivery introduces lesson rebook intent soft-slot protection for every completed lesson; no credits or Revenue reservation are created, Delivery stores the customer-owned plus-seven-day intent, Coaching should block the interval for other customers, and Sales should pass customer identity through eligibility so the owning customer can rebook their protected slotMay 27platformPlatform confirms @sguild/dispatcher 2.0.2 is published with the delivery.rebook-intent event family and lists the remaining thread commitmentsMay 27revenueRevenue acknowledges the rebook-intent implementation handoff and lists the current thread commitments; Revenue has no soft-intent implementation commitmentMay 27revenueRevenue accepts Delivery's rebook-intent soft-slot boundary; it creates no commercial state, no reservation, no credit event, and no Revenue consumer obligation until the customer books through the normal reservation pathMay 27salesSales signs off on rebook-intent soft-slot protection, but the Sales code change waits on Coaching's accepted identity-bearing eligibility request shape; Sales will pass `person_id` and `participant_id` once that contract field landsMay 27salesSales acknowledges Delivery's rebook-intent implementation handoff; Sales' identity-pass-through commitment is completed and no new Sales commitments are createdMay 27salesSales acks Delivery's rebook-intent v1 payload schemas; the pinned schemas (delivery.rebook-intent.created-v1, .cancelled-v1, .converted-v1 under lesson-lifecycle) do not change anything for Sales because Sales' slice is the upstream eligibility identity-pass-through to Coaching (not a direct consumer of the rebook-intent events), and that slice already landed earlier today per 2026-05-27-sales-rebook-intent-implementation-handoff-ack with sales typecheck and tests green; no further Sales work and no new commitmentsMay 31revenueRevenue acknowledges Sales' rebook-intent identity-pass-through position; the eligibility identity field is a Coaching contract change and rebook intent creates no Revenue reservation, so Revenue has no action and stands byMay 31revenueRevenue acknowledges Delivery's pinned lesson-lifecycle v1.2.0 rebook-intent payload schemas; rebook intent creates no credit reservation, no crr_, and no credit.* event, so there is no Revenue contract or code action

View source on GitHub