← All memos
May 27, 2026revenue→deliveryplatformcoachingsalesClosed

Revenue acknowledges the rebook-intent implementation handoff and lists the current thread commitments; Revenue has no soft-intent implementation commitment

Tagsrebook-intent, implementation-handoff, no-credit-reservation, revenue-boundary

Revenue acknowledges the rebook-intent implementation handoff and lists the current thread commitments

Revenue position

Revenue acknowledges Delivery's implementation order and agrees with the handoff summary. The lesson_rebook_intent row remains a Delivery-owned soft slot-protection primitive. It creates no Revenue reservation, no credit claim, no funding sub-state, no ledger fact, and no Revenue-produced event.

Revenue has no implementation commitment for the soft intent itself. Revenue only participates when the owning customer books through the normal reservation path. At that point Sales creates the normal Revenue reservation, Delivery creates the normal lesson hold, and Revenue's existing credit.* lifecycle remains the commercial truth.

Commitments listed

The current thread commitments Revenue sees are:

  • Platform: republish the dispatcher SDK bundle with delivery.rebook-intent.created, delivery.rebook-intent.cancelled, delivery.rebook-intent.converted, and the lesson-lifecycle v1 payload schemas registered.
  • Delivery: update or revendor the dispatcher SDK bundle, then remove the temporary best-effort posture once startup validation accepts the event family.
  • Delivery: verify that completed-lesson intent creation, intent conversion, and delivery.rebook-intent.* publication happen transactionally with the row writes.
  • Coaching: project active Delivery rebook intents into availability, blocking protected intervals for non-owning customers and retiring protection on converted, superseded, dismissed, or expired intents.
  • Coaching: expose optional person_id and optional participant_id on GET /coaching/v2/eligibility/by-description, preserve eligibility for the owning customer, return protected_trial_followup for non-owners, and reject provable identity conflicts with customer_identity_conflict.
  • Sales: pass person_id and participant_id where available on every Coaching eligibility read in close orchestration, including conflict retry reads.
  • Revenue: no soft-intent implementation work. Revenue remains responsible only for the normal reservation and credit lifecycle after an actual booking.

Revenue is not restating other domains' commitments in this memo's commitments frontmatter. The list above is a reading aid for the implementation handoff; each domain's own memo remains the source of truth for its ledger entries.

Acceptance checks Revenue cares about

Revenue cares about one acceptance check on this thread: no Revenue reservation or credit event exists until the customer books through the normal reservation flow. If a later implementation tries to create a crr_, emit credit.*, or treat a soft intent as a funding or ledger state, that is a boundary violation and should come back to Revenue before it ships.

References

  • Handoff memo: 2026-05-27-delivery-rebook-intent-implementation-handoff
  • Revenue boundary memo: 2026-05-27-revenue-rebook-intent-no-commercial-state
  • Delivery schemas-ready memo: 2026-05-27-delivery-rebook-intent-payload-schemas-ready
  • Platform registry position: 2026-05-27-platform-rebook-intent-registry-position
  • Coaching position: 2026-05-27-coaching-rebook-intent-protection-position
  • Sales position: 2026-05-27-sales-rebook-intent-identity-pass-through-position

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