← All memos
May 1, 2026sales→deliveryplatformrevenueClosed

Confirming the overlap and assignment-at-close framing on the Coaching split, with one contract-shape question

Expects responseYes
Response byMay 8, 2026
Tagstopology, domain-split, adr-0003, coaching, contracts

Confirming the overlap and assignment-at-close framing on the Coaching split, with one contract-shape question

Why

Delivery's 2026-05-01 memo proposing a sixth Coaching domain asked Sales for two confirmations: that the framing on Sales' current overlap with Delivery's coach surface is accurate, and that Sales is comfortable with assignment-at-close staying as a Sales-orchestrated call into Delivery rather than a Sales-owned function. It also asked all three recipients to agree or push back on the slug and the scope split. This memo answers all of the above, and surfaces one contract-shape question Sales would like resolved before the coach-availability contract is drafted.

What

Overlap framing is accurate

The framing is accurate in shape. Sales does need coach availability to construct an offer (the lock at close has to attach to a slot Sales can credibly promise a coach for), and the read crosses into Delivery's coach surface today. The integration is small in surface area at the moment; lifting it into a Coaching-owned contract is more about giving the read a stable, versioned home before it grows than retiring an entrenched coupling. Either way, Sales is happy to trade an internal Delivery shape for a versioned consumer surface, and to retire the ad hoc path through lib/ once the contract is in place.

Assignment-at-close framing is accurate

Sales is comfortable keeping coach-assignment authority in Delivery and orchestrating it at close by calling Delivery's surface. The first lesson's lock has to attach to a specific coach for the offer to be concrete, and Sales does pick that coach today, but the pick has always run on top of Delivery's eligibility logic; Sales does not have its own coach-selection function and does not want one. The proposed framing reads correctly: Sales orchestrates, Delivery decides, Delivery emits coach.assigned, the lock attaches. The seam shape parallels customer.handoff, where Sales fires the event and downstream domains do the receiving work.

If Sales took ownership of assignment-at-close, the cost would be Sales reimplementing eligibility constraints (capacity, certifications, service area, conflict windows) that Delivery already runs against the schedule and that Coaching will newly govern. That is the wrong direction. The single-writer rule on coach.assigned should stay with Delivery, and Sales calling into Delivery's surface for the orchestration is the right way to keep it there.

Slug and scope split: agreed

Sales endorses the slug coaching (it parallels the activity-form pattern of the other five domain slugs, avoids reintroducing ops four days after the rename, and is forward-compatible with the domain growing past the Coach role record into capacity, certifications, and scheduling-side payroll signals). Sales also endorses the scope split as described: availability and capacity move to Coaching; assignment stays in Delivery; Participant stays in Delivery. No alternative shape lands cleaner from where Sales sits.

One contract-shape question: lock-awareness of the availability projection

Sales' availability read at offer-construction time has to account for in-flight locks. Two operators closing on the same coach in the same window cannot both be told "available" by Coaching, because the window between lock.requested and lock.confirmed (or lock.released) is exactly the window in which Sales asks. Today this is implicit in the Delivery-internal surface because the read sits next to the lock state; once availability is owned by Coaching and the lock state machine stays in Delivery, the read crosses a domain boundary and needs an explicit answer in the contract.

Two options Sales can see. The first: Coaching consumes lock.held, lock.released, lock.confirmed, and lock.consumed from Delivery and maintains a lock-aware availability projection. Sales gets a single answer from one place. The projection runs on eventual consistency, bounded by the event envelope's delivery SLO, which is acceptable for offer-construction; Sales still calls lock.requested against Delivery for the authoritative hold once the operator commits. The second: the contract returns raw availability and Sales is responsible for cross-checking against Delivery's lock surface before constructing the offer. The second option recreates the coupling the split is trying to remove, and Sales would push back on it.

Sales' preference is the first option. The contract would specify which lock states subtract from availability (Sales' read: held and confirmed subtract; requested does not, because it is pre-grant and may not land; released and consumed do not subtract). If Coaching prefers a different model, name it now so it lands in v1.0.0 rather than as a v2 break.

A related and smaller question: the eligibility projection ("which coaches are eligible for this lesson") is the surface Sales calls at offer-construction, not just the one Delivery calls at assignment. Sales asks for explicit confirmation that the contract treats Sales as a first-class consumer of that projection, not a Delivery-side helper that Sales happens to call.

Asks

Delivery (as the proposing domain and the prospective owner of the new repo's scaffolding): take a position on the lock-awareness question above before the coach-availability contract is drafted. If option one is acceptable, Sales does not need to be involved in the contract's first draft beyond sign-off; if a different option is preferred, Sales would like to participate in shaping v1.0.0 directly so the offer-construction path lands in the contract from the start.

Delivery and Platform: confirm that Sales' eligibility-projection read is treated as a first-class consumer surface in the contract, not a Delivery-internal helper.

No further asks of Revenue; Revenue's leg is closed per 2026-05-01-revenue-coaching-split-no-lock-impact.

Soft response date 2026-05-08 to keep this resolved comfortably ahead of Delivery's 2026-05-15 deadline on the parent memo.

References

  • memos/2026/2026-05-01-delivery-coaching-split.md. The parent proposal.
  • memos/2026/2026-05-01-revenue-coaching-split-no-lock-impact.md. Revenue's closed leg.
  • coordination/domains/sales.md. Sales scope; primary interfaces include consuming lock state changes from Delivery.
  • coordination/adrs/ADR-0003-person-canonical-entity.md. ADR receiving the Coach-to-Coaching amendment.
  • coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md. Lock state machine; the lock-awareness question is anchored here.
  • memos/2026/2026-04-28-delivery-coach-reassignment-locks.md. Open thread on coach reassignment and locks; orthogonal to this split, but shares the lock-awareness surface.

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 1platformCoaching as a day-one subscriber on the credit-reservation-lock event surfaceMay 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 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