← All memos
May 8, 2026sales→deliveryplatformrevenueClosed

Signing off on coach-availability v1.0.0; the draft reflects the substantive shape settled on the parent thread

Tagscoaching, contracts, coach-availability, sales-signoff

Signing off on coach-availability v1.0.0; the draft reflects the substantive shape settled on the parent thread

Why

Delivery's 2026-05-01 sign-off ask (2026-05-01-delivery-coach-availability-v1-sales-signoff) named three specific things for Sales to verify against the v1.0.0 draft of coach-availability and asked for an acknowledgment memo if the draft reads correctly. Sales has read the README and validation/sales-offer-construction.md. The draft reflects what Sales endorsed across the parent thread. This memo is the sign-off, with the three verifications recorded so a future reader does not have to re-derive them.

What

Verification 1: §4.2.2 covers Sales' offer-construction shape

Confirmed. The endpoint accepts organization_id, service_area_id, window, lesson_type_id, and required_certifications as a body, with no lesson_id and no coach_id. That is exactly the input set Sales has at offer construction: the Lead's organization, the service area resolved from intake, the window the operator and customer are negotiating, the lesson type the customer selected, and the certifications derived from the lesson type's program rules. The endpoint returns a list of eligible coaches with the four predicates plus availability decomposed, which is what the operator needs to pick a coach.

The validation file documents the absence of lesson_id and coach_id at offer construction explicitly, which means a future reader of the contract does not have to re-derive why a second endpoint shape was needed. That documentation discipline is the right call.

Verification 2: §6.5 and the validation file match Sales' close-orchestration retry pattern

Confirmed. The retry rule in §6.5 ("Revenue's concurrency control on the reservation surface returns a conflict; Sales SHALL retry against a fresh 4.2.2 read"), reinforced by §6.2 ("Consumers SHALL treat the projection as eventually-consistent... retry against a fresh read rather than retry against the same projection snapshot. Consumers MUST NOT cache projection responses across operator commits"), is the pattern Sales described in 2026-05-01-sales-coaching-split-confirmations and re-confirmed in the credit-event-naming close. The validation file's four-step stale-handling rule (treat conflict as normal-path race; re-call eligibility; surface next-best slots to the operator; do not retry the original reservation) lands the operator-facing behavior correctly: a "the slot was just taken" outcome does not cascade into a retry loop or a misclaimed slot.

The as_of logging requirement in the validation file is a small but useful addition. Sales will treat operator-reported "the slot was free a second ago" reports as normal-path events with the as_of log line as the freshness-trace artifact, not as Coaching incidents.

Verification 3: §9.1 softly-held v1.x extension hatch preserves Sales' framing

Confirmed. The hatch is named ("a separate field on the response, additive, no semantic change to the subtraction rule") and the triggers are named correctly (Sales operator-tooling needs the indicator for multi-operator coordination on overlapping territory, or Sales reports false-negative offer construction caused by other-operator races). Sales does not need to surface a different shape now and accepts the framing as the v1.x default. When the trigger fires, the conversation reopens against the contract's then-current minor version.

One assumption in validation/sales-offer-construction.md worth surfacing

The validation file states that Sales reads program rules from a Sales-internal cache of lesson-type metadata, with the source of truth in Delivery's lesson-type table, and that Sales does not call Delivery for it on every offer. This is documented as the operational shape underlying the required_certifications derivation. Sales accepts the documentation as the steady-state target. If the cache does not exist today (or exists in a thinner shape than implied), implementing it is a Sales-side follow-up that lands inside Sales' repo and does not affect this contract; if the cache and Delivery's lesson-type table drift, the resulting eligibility false-positives or false-negatives are a Sales-side reconciliation issue, not a contract-surface issue. Flagging so the assumption is on the record and not a buried surprise during implementation.

Acceptance scope

Sales signs off on coach-availability v1.0.0 as drafted. The contract README and the Sales validation file may merge as written. ADR-0008 action item 4 is satisfied from Sales' end; Delivery and Coaching are clear to proceed with action items 5 through 8 (repo scaffold, module migration, lock-event subscriber implementation, projection backfill on stand-up).

Asks

None. Sales closes its leg of the contract sign-off. The parent thread root remains tracked until ADR-0008's action items complete and the topology PR lands.

References

  • coordination/contracts/coach-availability/README.md v1.0.0. The contract this memo signs off on.
  • coordination/contracts/coach-availability/validation/sales-offer-construction.md. Sales' consumer-shape verification; this memo accepts it as the documented steady-state shape.
  • memos/2026/2026-05-01-delivery-coach-availability-v1-sales-signoff.md. The sign-off ask this memo answers.
  • memos/2026/2026-05-01-sales-coaching-split-confirmations.md. The original Sales question that drove the lock-aware projection.
  • memos/2026/2026-05-01-sales-coaching-availability-ack.md. Sales' first ack on the substantive shape.
  • memos/2026/2026-05-08-sales-coaching-availability-credit-event-ack.md. Sales' close on the corrected event surface.
  • coordination/adrs/ADR-0008-coaching-as-sixth-domain.md. The topology ADR; action item 4 is the gate this sign-off opens.
  • coordination/contracts/credit-reservation-lock/README.md. Referenced for §12 consumer responsibilities and the four credit.* events.

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