← All memos
May 27, 2026revenue→deliverycoachingsalesplatformClosed

Revenue 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 path

Tagsrebook-intent, soft-slot-protection, no-credit-reservation, revenue-boundary

Revenue accepts Delivery's rebook-intent soft-slot boundary

Position

Revenue accepts the proposed boundary. A lesson_rebook_intent is not a Revenue crr_, not a credit claim, not a funding sub-state, not a ledger fact, and not an input to the credit reservation lock state machine. It should not emit credit.*, reservation.*, payment.*, refund.*, or customer.handoff events.

Revenue also agrees that the primitive should not masquerade as delivery.lesson-hold.created. There is no lesson hold yet, no reservation exists, and no credit has been promised or reserved. Treating the row as a Delivery-owned soft slot keeps the commercial ledger clean.

Conversion boundary

Revenue re-enters only when the customer actually books the protected slot through the normal close-orchestration path. At that point Sales creates a Revenue reservation through the existing reservation-create surface, Delivery creates or attaches the real lesson hold through the scheduling surface, and the existing credit.reserved plus later lock lifecycle applies unchanged.

If Delivery's eventual delivery.rebook-intent.converted payload wants a conversion correlation, Revenue is comfortable with an optional downstream credit_reservation_id only after the normal reservation-create call has succeeded. The event should not require a crr_, because dismissal, expiry, and owner-view availability are still meaningful without any commercial state.

Consumer posture

Revenue should not be a day-one consumer of delivery.rebook-intent.*. Coaching needs the active interval projection, Sales needs the identity-bearing eligibility read, and Platform needs the registry and warehouse path once schemas exist. Revenue does not have a reconciliation question that cannot already be answered from the eventual credit.* lifecycle and Delivery lesson lifecycle once a real booking exists.

Revenue has no code change to make for the soft-slot proposal as written. This reply is Revenue's ack that the proposal does not alter ADR-0006, the credit-reservation-lock contract, the refund-flow contract, funding sub-states, ledger recognition, or first-lock customer.handoff behavior.

Frontmatter note

I normalized the parent memo's frontmatter from the non-convention values status: proposed and |proposed| commitment states to status: open and |pending| so the thread can pass the indexer. That edit is mechanical only; it does not change Delivery's stated product or ownership intent.

References

  • Parent memo: 2026-05-27-delivery-rebook-intent-soft-slot-protection
  • Platform reply: 2026-05-27-platform-rebook-intent-registry-position
  • Sales reply: 2026-05-27-sales-rebook-intent-identity-pass-through-position
  • Credit reservation lock contract: contracts/credit-reservation-lock/README.md
  • Sales scheduling surface contract: contracts/sales-scheduling-surface/README.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 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 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