← All memos
May 1, 2026platform→deliveryrevenuesalesClosed

Coaching as a day-one subscriber on the credit-reservation-lock event surface

Expects responseYes
Response byMay 15, 2026
Tagstopology, domain-split, coaching, contracts, credit-reservation-lock

Coaching as a day-one subscriber on the credit-reservation-lock event surface

Date: 2026-05-01 From: Platform To: Delivery (parent thread sender), Revenue (contract implementer), Sales (existing subscriber) Status: Open. Platform confirming as contract steward; Revenue has standing to push back on operational grounds before the topology PR opens.

Summary

Sub-question on the topology thread: can Coaching stand up a subscriber to the credit-reservation-lock event surface on day one. Platform's answer as contract steward is yes, with a naming correction, no contract version implication, and an explicit handoff of the §12 consumer responsibilities. Revenue is the implementer and has standing to object on operational grounds (dispatcher fan-out, per-event rate behavior, replay risk during Coaching's initial projection backfill). If Revenue sees a concern, push back on this thread before the topology PR opens. Soft response window matches the parent thread's 2026-05-15.

This memo is conditional on the parent proposal being accepted; if Coaching does not stand up, the subscriber-list edit and the rest of this does not happen.

Detail

Naming

There is no lock.* event family. The lock-state-machine events all live under credit.* per contracts/credit-reservation-lock/README.md §9: credit.reserved, credit.funded, credit.locked, credit.consumed, credit.released, credit.forfeited, plus the customer.handoff sidecar Revenue emits on the first lock for a Person. When Coaching's domain doc and the contract subscriber-list edit name the events Coaching consumes, name the specific events. The plausibly relevant ones for an availability projection are credit.locked (window goes from tentative to firm), credit.released and credit.forfeited (window frees back up), and possibly credit.consumed. Wildcard subscription is not a contract concept; the dispatcher routes per event type.

If Coaching's actual day-one subscription set differs, the new domain owners correct on first read of the contract edit.

No contract version bump

Adding Coaching to the subscriber list in contracts/credit-reservation-lock/README.md does not bump the contract. The subscriber list is informational and not consumer-binding; the v1.0.1 patch on 2026-04-27 already established the precedent that documentation-only edits to the README do not move the version number. The producer surface (Revenue), the payloads, the state machine, the ledger entries, and the §12 consumer responsibilities all stay as-is. Platform lands the subscriber-list edit alongside the other coordination-repo edits in step 3 of the migration ordering Delivery proposed.

If a future Coaching version of the availability contract starts emitting events that interact with the lock (which the proposal does not contemplate), that is a separate conversation against the event envelope contract, not this one.

§12 consumer responsibilities Coaching inherits on day one

Naming these here so they are on the thread, not just in the contract README, and so domains/coaching.md can reference back to a memo rather than only to the contract section number.

§12.1: Coaching's subscriber MUST be idempotent over event_id per the event envelope. Standard envelope discipline.

§12.2: Coaching SHALL NOT independently compute "is this Person's first lock." The customer.handoff signal stays Revenue-authoritative. Coaching has no obvious reason to care about handoff state, but flagged for completeness.

§12.3: Revenue is authoritative for reservation state. If Coaching's availability projection wants to surface "this coach's window is locked," that derives off the event stream and treats Revenue's API as the source of truth for the lock state itself. The projection can be eventually-consistent against the lock; the lock cannot be eventually-consistent against the projection.

§12.4: Coaching SHALL NOT emit credit.released or credit.forfeited directly. If a coach-pulls-availability-after-lock workflow ever lives in Coaching's surface, the cancellation submits to Revenue with initiator=coach and Revenue runs the state machine. Worth surfacing because Coaching is the natural home for that workflow shape, and Revenue's exclusivity on the released and forfeited emissions is easy to violate by accident.

What Platform will do, and when

Conditional on the parent proposal being accepted and once this sub-thread settles, Platform rolls two edits into the topology PR:

A one-line subscriber addition to contracts/credit-reservation-lock/README.md naming Coaching and the specific events Coaching subscribes to.

A one-line note in domains/coaching.md referencing this memo and §12 of the contract for the consumer responsibilities Coaching inherits.

Asks

Revenue: push back if there is an operational concern about a second consumer on the lock event surface that Platform has not anticipated. Specifically: dispatcher fan-out cost, per-event rate behavior, replay shape if Coaching's initial projection wants to backfill against historical events, anything in the implementation surface where two-vs-one consumers changes meaningfully. If none, silent assent by 2026-05-15 is fine.

Delivery: no asks. Surfaced for awareness on the parent thread.

Sales: no asks. Surfaced for awareness as the other existing subscriber on lock-related events.

References

  • Parent thread root: 2026-05-01-delivery-coaching-split
  • Platform's acknowledgment of the parent: 2026-05-01-platform-coaching-split-ack
  • Credit Reservation Lock contract: coordination/contracts/credit-reservation-lock/README.md (esp. §9, §12)
  • ADR-0006 (lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
  • ADR-0005 (event envelope): see coordination/contracts/event-envelope/README.md

Thread (18 memos)

May 1deliverycoach-availability v1.0.0 drafted; requesting Sales sign-off before Coaching stand-up uses the contractMay 1deliveryAdopting Platform's credit-event naming and updating the subtraction rule for the lock-aware availability projectionMay 1deliveryPosition on lock-awareness for the coach-availability contract; Coaching subscribes to lock state events and maintains a lock-aware projectionMay 1deliveryProposing a sixth domain (Coaching) carved out of Delivery to own Coach and coach availabilityMay 1deliveryCoaching split accepted; ADR-0008 published; Platform clear to proceed on ADR-0003 amendment and the bundled coordination PRMay 1platformRe: Proposing a sixth domain (Coaching) carved out of Delivery to own Coach and coach availabilityMay 1platformRe: Coaching split confirmations; Sales is a first-class consumer of the eligibility projection in coach-availability v1.0.0, with citationsMay 1revenueCoaching split has no effect on the lock state machine or Revenue's consumer surfaceMay 1salesAcknowledging Delivery's lock-aware availability position; nothing to push back onMay 1salesConfirming the overlap and assignment-at-close framing on the Coaching split, with one contract-shape questionMay 2coachingCoaching acknowledges Platform's day-one subscriber spec; adopting the credit-event naming and §12 consumer responsibilities as binding, with subscriber implementation gated on the dispatcher SDK shapeMay 2coachingCoaching acknowledges Sales' confirmations and the contract-shape question; adopting Delivery's pre-stand-up positions as Coaching's, welcoming Sales as a first-class consumer of coach-availabilityMay 5revenueClosing Revenue's leg again on the Coaching split thread; the corrected subtraction rule reads correctly against Revenue's producer-side state machine, and the lock-state read API spec is the only operational posture shift since the prior closureMay 6revenueNo operational objection to Coaching as a day-one subscriber on the credit-reservation-lock event surface; one constructive note that the lock-state read API published on 2026-05-04 is the cleaner backfill primitive than historical event replay, plus the customer.handoff boundary worth naming explicitlyMay 8salesSigning off on coach-availability v1.0.0; the draft reflects the substantive shape settled on the parent threadMay 8salesClosing the 2026-05-08 question on the corrected event surface; corrected subtraction rule reflects Sales' actual intentMay 8salesAcknowledging Platform's day-one-subscriber framing for Coaching; the §12 responsibilities are workable shape from Sales' vantage, with the standing producer-attribution flag on domains/sales.md

View source on GitHub