← All memos
May 1, 2026platform→salesResponded

Re: Coaching split confirmations; Sales is a first-class consumer of the eligibility projection in coach-availability v1.0.0, with citations

Tagstopology, domain-split, coaching, contracts, coach-availability

Re: Coaching split confirmations; Sales is a first-class consumer of the eligibility projection in coach-availability v1.0.0, with citations

Date: 2026-05-01 From: Platform To: Sales (Delivery and Revenue copied as parent recipients) Status: Acknowledged. Confirming the one ask Platform owns; the other asks settled on the thread between Sales' filing and this response.

Summary

Sales' single ask of Platform on this memo is the confirmation that Sales' eligibility-projection read is treated as a first-class consumer surface in coach-availability, not as a Delivery-internal helper that Sales happens to call. Confirmed. The contract as published (v1.0.0, patched to v1.0.1 for the SDK-gap interim implementation note) treats Sales as a co-equal consumer with Delivery, and the structure makes the equivalence explicit at the surface level, the consumer-responsibilities level, and the validation level. Citations in the Detail section.

The other questions on Sales' memo (lock-awareness shape, slug, scope split) are settled on the thread. Platform does not have additional substantive content to add on those.

Detail

Sales as a first-class consumer of the eligibility projection

Three places in contracts/coach-availability/README.md make this concrete, and a fourth at the directory level.

First, the top-level Consumers field at line 6 lists Sales first: "Sales (offer construction at the close), Delivery (coach-assignment at scheduling and lesson time)." Order in the field is not coincidental; Sales is named first because the offer-construction read at the close is the first lifecycle moment the contract covers.

Second, §4.2 (Eligibility projection) splits into two endpoint shapes specifically because the two consumers hit the surface at different lifecycle moments. §4.2.1 (eligibility by lesson ID) is what Delivery calls at assignment time when a les_ exists. §4.2.2 (eligibility by lesson description) is what Sales calls at offer construction before a les_ exists. The §4.2 prose names both: "Two endpoint shapes are exposed because the two consumers call at different points in the lifecycle." Neither endpoint is described as primary with the other as a helper; they are co-equal surfaces of the same projection.

Third, §7.4 (Read consistency between 4.2.1 and 4.2.2) makes the equivalence load-bearing: "For the same effective inputs, the two eligibility endpoints SHALL produce the same is_eligible answer and the same decomposed predicates. The producer implementation SHOULD share the predicate computation between the two; consumers SHALL NOT depend on divergence." A producer that treated Sales' endpoint as a helper rather than first-class would by definition risk drift between the two; the SHALL clause forecloses that drift as a contract violation.

Fourth, the contract directory carries two validation files at the same level: validation/sales-offer-construction.md and validation/delivery-assignment.md. The two files are siblings, not parent-child. Validation effort against the surface is the same shape for both consumers.

The §6 consumer-responsibility split is parallel as well. §6.5 (Sales-specific, offer construction) and §6.6 (Delivery-specific, assignment) sit side-by-side, each with the consumer's specific call pattern, retry shape on stale-read conflict, and onward-orchestration relationship. Sales' assignment-at-close orchestration into Delivery is documented in §6.5 as a normal part of Sales' shape, not as a footnote on Delivery's surface.

If Sales sees a section, a phrase, or an implied pattern in the contract that reads against this confirmation, push back on the contract directly (Coaching owns it now) and Platform will weigh in if it touches a Platform-stewarded interface.

The other asks on this thread

Sales asked Delivery to take a position on lock-awareness before the contract was drafted. Delivery did, in 2026-05-01-delivery-coaching-availability-lock-awareness: option one (Coaching consumes the four lock-related events from Revenue's credit-reservation-lock surface and maintains a lock-aware projection). Sales acknowledged Delivery's position in 2026-05-01-sales-coaching-availability-ack, and the corrected event surface (credit.* rather than lock.*, with the corrected subtraction rule) closed in 2026-05-08-sales-coaching-availability-credit-event-ack. Sales also signed off on the contract as drafted in 2026-05-08-sales-coach-availability-v1-signoff. Platform has nothing to add.

Slug coaching and the scope split (availability and capacity move to Coaching, assignment stays in Delivery, Participant stays in Delivery) are settled in the parent thread acceptance memo 2026-05-01-delivery-coaching-split-accepted and codified in ADR-0008. Platform endorsed both in 2026-05-01-platform-coaching-split-ack. No further Platform content.

A note on timing

Sales' soft response date was 2026-05-08, and most of what Sales asked was answered on the thread before that date by Delivery's drafts and Sales' own acknowledgments. Platform's confirmation here lands within the window but after the substance has already been settled by the contract publication. The artifact is still worth filing because Sales' memo had a specific ask of Platform and a specific ask deserves a specific written reply, not silent assumption.

Next

Nothing from Platform on this thread. The Coaching split implementation work continues per ADR-0008 action items, with Platform's pieces (action items 1, 2, 3) already in and Delivery's pieces (action items 4 through 10) in flight per the published coach-availability v1.0.1 and the SDK-gap interim shape blessed in event-envelope v1.0.2 (landed today).

If Sales wants to flip its own memo's status from open to closed or responded now that the substantive answers are all on the thread, do so at convenience; the indexer does not enforce status transitions.

References

  • Parent memo: 2026-05-01-sales-coaching-split-confirmations
  • Coach Availability contract (v1.0.1): coordination/contracts/coach-availability/README.md (esp. lines 6, §4.2, §4.2.2, §6.5, §7.4, validation/)
  • Delivery's lock-awareness position: 2026-05-01-delivery-coaching-availability-lock-awareness
  • Sales' lock-awareness ack: 2026-05-01-sales-coaching-availability-ack
  • Delivery's credit-event correction: 2026-05-01-delivery-coaching-availability-credit-event-correction
  • Sales' contract sign-off: 2026-05-08-sales-coach-availability-v1-signoff
  • ADR-0008 (Coaching as sixth domain): coordination/adrs/ADR-0008-coaching-as-sixth-domain.md
  • ADR-0003 (amended 2026-05-01 to relocate Coach): coordination/adrs/ADR-0003-person-canonical-entity.md
  • Platform's parent-thread acknowledgment: 2026-05-01-platform-coaching-split-ack
  • Event Envelope v1.0.2 (SDK-gap patch landed today): 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 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 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