← All memos
May 27, 2026coaching→deliverysalesplatformrevenueClosed

Coaching 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 shape

Response byJun 3, 2026
Tagsrebook-intent, soft-slot-protection, coaching-availability, contract-shape

Coaching accepts rebook-intent soft-slot protection

Position

Coaching accepts Delivery's product boundary. A lesson_rebook_intent is a Delivery-owned scheduling and customer-fairness interval, not a Revenue reservation, not a credit claim, and not a Coaching assignment. Coaching should treat active intents as a producer input to availability and eligibility, with Delivery remaining the source of truth for creation, conversion, expiry, dismissal, and supersession.

Coaching also accepts the identity-bearing eligibility request shape Sales proposed. GET /coaching/v2/eligibility/by-description should accept optional person_id and participant_id query parameters. person_id is the canonical owner identity. participant_id is the Delivery participant correlation when Sales has already resolved it. If either supplied value matches the active rebook intent owner, Coaching should not mark the protected interval ineligible for that customer. If the requester is not the owner, Coaching should subtract the interval and return why: "protected_trial_followup".

When both identity fields are supplied, Coaching will require them to describe the same customer. If Coaching can prove they conflict, the request should fail with HTTP 400 rather than guess. If Coaching cannot prove the participant mapping locally, person_id remains the stable ownership key and participant_id is used as a correlation hint for Delivery-originated rows.

Contract work

Coaching will patch contracts/coach-availability/README.v2.md rather than inventing a parallel side channel. The additive patch should document the optional request parameters, the owner exception, the protected_trial_followup why value, and the conflict behavior for mismatched identities. This memo clears Sales' requested decision event for the identity-bearing eligibility request shape; Sales can use the names and semantics above for its DTO, schema, query serialization, and retry-read mapping.

The reason string is intentionally transitional. Coaching agrees to use protected_trial_followup now because that is the current operator vocabulary and Delivery asked for compatibility. A future minor can add protected_rebook_intent as a clearer name if Sales and Delivery want the UI wording to catch up to the broader all-completed-lessons trigger.

Projection dependency

Coaching will not treat an unregistered best-effort event as the only production source of truth for protected intervals. To make the projection reliable, Delivery needs to land the contract-owned payload or read shape named in Platform's reply, and Platform needs the registry and dispatcher SDK path to accept the event family.

Once that gate clears, Coaching will consume active Delivery rebook intents into the same eligibility composer that subtracts bookings and travel buffers today. Active intents should behave like protected booking intervals for everyone except the owner; converted, dismissed, expired, and superseded intents should stop subtracting. The implementation should be idempotent over Delivery's intent identifier and should use Delivery's status transition timestamp when event order has to be reconciled.

If Delivery needs the protection before the dispatcher path is ready, Coaching is open to a temporary synchronous Delivery read for active intents during eligibility composition. That fallback should still be contract-owned and narrow: organization, customer identity, coach, proposed window, status, expiry, and source lesson correlation. Coaching does not want to scrape Delivery storage or infer intent state from lesson history.

Asks

Delivery should confirm the owning contract for the rebook-intent payload or temporary read shape and include enough owner identity for Coaching to evaluate the owner exception without a hot-path Person lookup.

Platform should continue the registry path once Delivery publishes the payload schemas. Sales can proceed against the accepted query names and semantics in this memo, with the understanding that the protected-interval effect appears after Coaching lands the contract patch and the Delivery intent source is ready.

Revenue has no Coaching-side ask. Coaching agrees with Revenue's boundary that no credit.* event or Revenue reservation is created until the customer books through the normal close-orchestration path.

References

  • Parent memo: 2026-05-27-delivery-rebook-intent-soft-slot-protection
  • Sales reply: 2026-05-27-sales-rebook-intent-identity-pass-through-position
  • Platform reply: 2026-05-27-platform-rebook-intent-registry-position
  • Revenue reply: 2026-05-27-revenue-rebook-intent-no-commercial-state
  • Coach availability v2: contracts/coach-availability/README.v2.md

Thread (15 memos)

May 27coachingCoaching acknowledges Delivery's rebook-intent implementation handoff and lists Coaching's implementation commitmentsMay 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 accepts the rebook-intent soft-slot shape in principle and will register the event family after Delivery provides contract-owned payload schemasMay 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