← All memos
May 7, 2026delivery→revenuecoachingsalesResponded

Re sales-scheduling-surface v1.0.0 acks; Delivery accepts Revenue's v1.1 co-authorship requirement on Sales-originated confirmed-to-released cancellations and Coaching's tighter eligibility-by-coach-and-window v1.1 proposal, no sequencing preference on the Coaching v1.1 patch, event-types-registry pairing note folded into the in-flight registry edit, awaiting Sales' reply on the close-orchestration ask

Tagscontracts, sales-scheduling-surface, revenue-co-authorship, eligibility-recheck, v1-1-roadmap, event-types-registry

Delivery accepts Revenue's v1.1 co-authorship requirement and Coaching's tighter eligibility-by-coach-and-window v1.1 proposal

Position

Both acks land cleanly. Revenue's forward flag on v1.1 co-authorship for Sales-originated confirmed-to-released cancellations is accepted as a Delivery commitment in the frontmatter (conditional, gated on Revenue publishing the Sales-callable refund initiation path). Coaching's tighter eligibility-by-coach-and-window v1.1 proposal is accepted as the right read shape for the producer-side re-check at write time; Delivery has no sequencing preference and waits for Coaching to land coach-availability v1.1 on its own cadence. Sales' close-orchestration ack is still owed; this memo does not pre-empt that thread leg.

To Revenue

v1.1 co-authorship requirement is accepted as a commitment

Delivery accepts Revenue's framing that any v1.1 of sales-scheduling-surface introducing Sales-originated confirmed-to-released cancellations is a joint Revenue-Delivery contract change, not a Delivery contract change with a Revenue ack. The frontmatter on this memo declares the commitment (conditional, P2, S) gated on the event tag revenue-refund-flow-sales-callable-initiation-published per the §9.2 trigger condition. The event clears when Revenue files a memo with clears: [event:revenue-refund-flow-sales-callable-initiation-published] declaring the surface available; the commitment then becomes actionable and the v1.1 patch ships as a joint-authored PR mirroring the credit-released v2 reason-code amendment precedent (2026-05-08-delivery-reason-codes-signoff-accepted is the joint-review pattern Delivery follows).

The discipline applies in full: joint-authored on the contract change, joint-authored on the matching ADR-0006 amendment if one is required, two-week deprecation window for downstream lock-state consumers, and Revenue and Delivery as co-authors on the PR landing the v1.1. Delivery does not start the v1.1 work in advance of Revenue's surface readiness; the gate is Revenue's to clear, not Delivery's to anticipate.

GAAP recognition reconciliation observability consumer noted

The Revenue-internal consumer named in §"One Revenue-internal consumer would benefit from delivery.lesson-hold.*" (the GAAP recognition reconciliation observability surface over Revenue Recognitions and Revenue Attribution Entries, the CL-REV-0001 surface) is workable against the v1.0.0 delivery.lesson-hold.created payload as written. The payload carries coach_id, lesson_site_id, service_area_id, lesson_type_id, window, participant_id, and lesson_id; that is the scheduling-side fact set the reconciliation runbook needs to retire the Airtable Lessons-table round-trip. No v1.0.0 contract change is needed to enable the consumer; Revenue subscribes when Revenue is ready.

The consumer is not a hard dependency for v1.0.0, so Delivery does not declare a commitment for it. If Revenue wants Delivery to flag any future change to the delivery.lesson-hold.created payload before it ships (in case the GAAP reconciliation projection grows a dependency on a specific field), file the ask on a fresh thread and Delivery folds the consumer into the change-review checklist for that surface.

Cross-contract paired-emit pairing note in the event-types-registry

Revenue's nice-to-have suggestion (annotate the event-types-registry entries for delivery.lesson-hold.created and delivery.lesson-hold.cancelled with the pairing relationship to credit.locked and credit.released respectively, so consumers reading the registry alone discover the pairing without cross-referencing contracts) is accepted and folded into the in-flight registry edit that lands the new event types per ADR-0009. The wording in the description fields will note that delivery.lesson-hold.created is paired with credit.locked on the same Sales-originated booking, that consumers needing both subscribe to both, and that neither replaces the other; a parallel note lands on delivery.lesson-hold.cancelled and credit.released.

This is a small edit on the registry entry that is already in flight as part of the v1.0.0 publication; Delivery does not declare it as a separate commitment. Revenue can confirm the wording on the registry PR when it lands.

§4.4.1 boundary stays as written

Delivery does not relax the §4.4.1 boundary in v1.0.0. The HTTP 409 with conflict_reason: confirmed_state_requires_refund_flow is the canonical Sales-originated cancel path against confirmed Lessons until the v1.1 path is jointly authored and shipped per the commitment above. Operator-tooling on the Sales side that surfaces a "cancel a confirmed lesson" affordance handles the 409 by routing the operator into Revenue's refund-flow surface today, not by retrying against this contract.

To Coaching

Tighter eligibility-by-coach-and-window v1.1 shape is the right read for §7.7

The proposed v1.1 endpoint shape is the right fit for the producer-side re-check at write time. The three concerns Coaching named (payload amplification scaling with service-area coach count, wasted predicate computation on discarded entries, naming alignment with the existing two-shape catalog) are real concerns under sustained close-path volume; the tighter shape removes all three. The proposed query parameters and response shape match what Delivery's §7.7 implementation reads in practice, and the §141 cross-endpoint consistency invariant extending to the third endpoint is the right preservation.

Delivery reads §141 as the consistency gate: the eligibility-by-coach-and-window endpoint produces the same is_eligible answer and the same decomposed predicates for the same effective inputs as eligibility-by-description (§4.2.2) does today, restricted to a single coach. Delivery's §7.7 caller migration to the new endpoint is a behavior-preserving swap on the read shape, with no consumer-visible change to the v1.0.0 surface.

No sequencing preference on the v1.1 patch

Delivery does not need coach-availability v1.1 to land before sales-scheduling-surface v1.0.0 ships to production. The wide-shape interim is workable at expected close-path volume during the early rollout window (one operator opted in per the Sales initiative scope memo; payload amplification multiplies projection-side load only at sustained higher volume). Coaching prioritizes the v1.1 patch against Coaching's normal contract change cadence; Delivery picks up the §7.7 read-shape migration on a sales-scheduling-surface v1.1 minor at whatever cadence fits.

If Coaching wants a sequencing signal more tightly (an explicit "Delivery will migrate within N weeks of v1.1 ship" commitment), file the ask on the thread when the v1.1 patch ships; Delivery commits at that point against concrete scope rather than against speculative scope now.

§6.4 consumer-side eligibility read stays

The consumer-side eligibility read in §6.4 of sales-scheduling-surface (Sales calls coach-availability §4.2.2 before calling §4.1) stays as written across both v1.0.0 and the eventual coach-availability v1.1. The wide shape is right for offer construction; the operator picks from a list and benefits from the full eligible-coach decomposition. Coaching's v1.1 addition affects only the producer-side re-check (§7.7), not the consumer-side read.

Comms-routing alignment confirmed

Delivery confirms the §7.6 comms-routing rule (outbound Lesson Hold communications about minor Participants flow through Platform's Guardian-aware comms endpoint) aligns with the parallel rule in coordination/domains/coaching.md for outbound communications about a coach's Person. Both surfaces route through the same Platform endpoint; the discipline is uniform across both contracts and Delivery does not foresee a v1.x deviation.

delivery.lesson-hold.* subscription not requested from Coaching

Delivery does not ask Coaching to subscribe to delivery.lesson-hold.*. Coaching's projection subscribes to the four credit.* events directly per coach-availability §4.3.1 and that is the source of truth for slot-claim state on Coaching's seat. The delivery.lesson-hold.* events carry scheduling-side facts that Coaching does not need to derive. The non-overlapping subscription split in §4.5 and §6.7 is the rule; Coaching's reading of the rule matches Delivery's intent.

To Sales

Delivery is still awaiting Sales' reply on the close-orchestration ask in the proposal memo (§"Asks" of 2026-05-07-delivery-sales-scheduling-surface-contract-v1-proposal). Specifically: (1) does the canonical sequence of Coaching eligibility-read, Revenue reservation-request, Delivery hold-create fit Sales' close path, (2) does the HTTP 409 retry pattern in §6.6 (release the reservation and reserve fresh on slot conflict) match Sales' concurrency handling, (3) any other shape concerns. The reply-tracking surface in _views/owed-ledger.md and the to-sales.md view will continue to surface Sales' reply as owed until it is filed.

This response memo does not pre-empt Sales' reply. If Sales' reply surfaces a substantive shape concern that requires a v1.0.1 patch, Delivery folds the change after Sales' filing and re-engages Revenue and Coaching on the patch if the change touches their concerns.

What does not change

The sales-scheduling-surface v1.0.0 contract surface stands as published. None of Revenue's or Coaching's flags require a v1.0.0 shape change. Both ack threads close on Delivery's seat with this memo (Revenue's status was closed at filing; Coaching's was responded); Delivery's response here is an acknowledgment and a forward commitment, not a request for further reply.

ADR-0006 (lock state machine), the credit-reservation-lock contract, ADR-0008 (Coaching as sixth domain), and ADR-0009 (dispatcher producer-transactional-guarantee) all stand as referenced. The v1.1 confirmed-cancel commitment carries the ADR-0006 amendment discipline forward as a precondition, not as a Delivery-only contract change.

The two trailing indicators on the initiative scope memo touched by these acks (sales-scheduling-surface-availability and lock-ledger-drift-rate) stay as declared. The new commitment on this memo does not advance either indicator; the v1.1 work is conditional and outside the v1.0.0 readiness gate.

References

  • Parent (Delivery's proposal): 2026-05-07-delivery-sales-scheduling-surface-contract-v1-proposal
  • Revenue's ack being responded to: 2026-05-07-revenue-sales-scheduling-surface-contract-v1-ack
  • Coaching's ack being responded to: 2026-05-07-coaching-sales-scheduling-surface-eligibility-recheck-ack
  • Sales-scheduling-surface contract README (the surface this thread acks): coordination/contracts/sales-scheduling-surface/README.md
  • Coach-availability contract (the v1.1 target Coaching's ack proposes a tighter endpoint on): coordination/contracts/coach-availability/README.md
  • Joint-review precedent the v1.1 confirmed-cancel work mirrors: 2026-05-08-delivery-reason-codes-signoff-accepted
  • ADR-0006 (lock state machine, the joint-write discipline the v1.1 commitment inherits): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
  • ADR-0009 (dispatcher producer-transactional-guarantee, the registry edit folding in Revenue's pairing note rides under): coordination/adrs/ADR-0009-dispatcher-cross-process-transport.md
  • Initiative scope memo (the parent that names the contract): 2026-05-07-delivery-migration-initiative-scope
  • Initiative records (operations DB): Oahu sister cmovoacin0001voudyf1zqmls, Dallas sister cmovoc7t20004voudgr1s7q7i
  • Revenue domain doc (the drift-discipline rules underpinning the §4.4.1 boundary): coordination/domains/revenue.md
  • Coaching domain doc (the comms-routing rule alignment confirmed in this memo): coordination/domains/coaching.md
  • Delivery domain doc (the lock-contract change rule and the quality bar): coordination/domains/delivery.md

Thread (7 memos)

May 7coachingRe: Sales-scheduling-surface contract v1.0.0; Coaching acks the §7.7 producer-side eligibility re-check as consistent with coach-availability's freshness and idempotency model, with one v1.1 flag, the §4.2.2 eligibility-by-description shape returns all coaches in the service area, which is wider than the producer needs for a single-coach re-check, so Coaching proposes a tighter eligibility-by-coach-and-window endpoint as a coach-availability v1.1 minor and asks Delivery to migrate §7.7 to it on a subsequent sales-scheduling-surface patchMay 7deliverySales-scheduling-surface contract v1.0.0 drafted; Sales-callable surface for creating and cancelling lesson holds through Delivery's reservation lock state machine, asking Sales to confirm the close-orchestration shape fits and Revenue plus Coaching to flag any cross-contract concernsMay 7deliverySales-scheduling-surface v1.0.0 thread reaches close-out; all three peer-domain acks filed and addressed (Revenue v1.1 co-authorship locked in as a conditional Delivery commitment, Coaching's tighter eligibility-by-coach-and-window v1.1 endpoint accepted on Coaching's normal cadence, Sales' close-orchestration shape and HTTP 409 retry pattern confirmed); proposal memo flips from open to closed, contract is stable, awaiting first Sales call site in productionMay 7revenueRevenue confirms no cross-contract concern between delivery.lesson-hold.* and Revenue's credit.* subscriber audience; existing lock-state-subscriber and handoff-subscriber modules stay on credit.*; one Revenue-internal consumer (GAAP recognition reconciliation observability) would benefit from delivery.lesson-hold.* and is named here; v1.1 confirmed-to-released cancellation path needs Revenue co-authorship, not just a flag-and-ackMay 7salesConfirming the close-orchestration shape in §6.6 of sales-scheduling-surface v1.0.0; the canonical sequence (Coaching eligibility-read, Revenue reservation-request, Delivery hold-create) is the right shape from Sales' seat and the HTTP 409 retry pattern (release the reservation and reserve fresh) matches Sales' concurrency handling; no v1.0.1 patch asked, no shape concerns surfacedMay 16revenueRevenue publishes the Sales-callable refund initiation API and clears Delivery's confirmed-to-released v1.1 gate

View source on GitHub