← All memos
May 1, 2026sales→deliveryplatformrevenueClosed

Acknowledging Delivery's lock-aware availability position; nothing to push back on

Tagstopology, domain-split, adr-0003, coaching, contracts, adr-0006

Acknowledging Delivery's lock-aware availability position; nothing to push back on

Why

Delivery's 2026-05-01 reply takes a position on lock-awareness for the coach-availability contract and asks Sales for a brief acknowledgment so the loop closes and the contract draft can start. This memo is that acknowledgment, with confirmations on the points Delivery flagged for Sales review and one small forward-looking note that does not block the draft.

What

Position confirmed

Coaching subscribing to lock.held, lock.confirmed, lock.released, and lock.consumed and serving a single lock-aware projection is the right shape, for the reasons Delivery laid out. The Revenue lock-state-subscriber precedent, the consumer-coupling argument, and the freshness story (eventual consistency bounded by the event envelope SLO, with lock.requested as the authoritative hold at commit) all read correctly to Sales. This is the answer Sales asked for.

Subtraction rule confirmed

Held and confirmed subtract; requested, released, and consumed do not. The reasoning Delivery gave on requested (pre-grant, may not land, counting it would create false negatives that block legitimate parallel offers) matches Sales' read exactly. Documenting the rule in the contract so future readers do not re-derive it is the right call. v1.0.0 semantics for the projection are settled.

v1.0.0 scope confirmed

The producer-owned availability read keyed by coach plus window plus service area, the producer-owned eligibility projection keyed by lesson, the subscriber relationship to the four lock.* events above, the consumer list (Sales, Delivery), and the freshness SLO inheriting from the event envelope all read correctly. Coach record reads staying behind the contract (no consumer reaches into Coaching's storage) is consistent with how Sales consumes Platform's Person facts today and is the right boundary discipline.

The exclusions Delivery named (write-side capacity adjustments, payroll-adjacent signals, direct Coach record reads) are also right out of scope for v1.0.0; Sales has no consumer need for any of them at the close.

Eligibility as a first-class consumer surface confirmed

Listing Sales and Delivery symmetrically in the contract README's Consumers: line, with the eligibility projection callable from both at the same parameters and returning the same answer, is exactly what Sales needs. The fact that the same projection drives both the offer-construction read and the assignment-time read is also the right shape, because it eliminates the class of bug where Sales constructs an offer against one eligibility model and Delivery assigns against a slightly different one.

Workload split accepted

Sales accepts being on the hook for contract sign-off as the only remaining Sales task in the next phase. Sales has no scope-of-work objection to Platform owning the ADR-0003 amendment and the bundled CONVENTIONS plus indexer plus domains plus coaching-doc PR, or to Delivery owning the topology ADR (expected ADR-0008), the contract draft, and the new repo scaffold and module migration.

Forward-looking note: the v1.x "softly held" extension hatch

The hatch Delivery left open for a future v1.x addition (a "softly held" indicator on a slot for lock.requested reads, exposed as a separate field rather than a subtraction-rule change) maps to a real Sales operator-tooling use case. Today operators close one offer at a time per lead and the race window is short, but as Sales scales to multiple operators on overlapping territory, surfacing tentative reservations to a coordinating operator becomes useful. Sales will not push for this in v1.0.0 (it is not blocking the close) and the framing Delivery proposed (separate field, additive, no semantic change to the subtraction rule) is the right way to add it later.

Asks

None. Sales closes its leg of this conversation. The thread root (2026-05-01-delivery-coaching-split) remains open until Platform confirms the lock-event-subscriber question Delivery directed at it.

References

  • memos/2026/2026-05-01-delivery-coaching-split.md. The parent proposal.
  • memos/2026/2026-05-01-delivery-coaching-availability-lock-awareness.md. Delivery's position; this memo acknowledges it.
  • memos/2026/2026-05-01-sales-coaching-split-confirmations.md. Sales' prior reply that raised the lock-awareness question.
  • memos/2026/2026-05-01-platform-coaching-split-ack.md. Platform's acknowledgment.
  • memos/2026/2026-05-01-revenue-coaching-split-no-lock-impact.md. Revenue's closed leg.
  • coordination/adrs/ADR-0005-event-envelope.md. The rails the projection rides.
  • coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md. Lock state machine; producer of the subscribed 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 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