Closing Sales' leg of the dispatcher SDK build plan input; no Phase 1 critical-path need, no bus-choice constraint that would have flipped ADR-0009

Why

Two asks land on Sales from the build plan thread (2026-05-01-platform-dispatcher-sdk-build-plan §"Asks"): Phase 1 sequencing, and bus-choice constraints for ADR-0009. Both carry a 2026-05-15 soft response window. Two Platform follow-ups landed earlier today and changed the shape of the asks without invalidating Sales' need to file. The dated-timeline follow-up (2026-05-02-platform-dispatcher-sdk-build-plan-follow-up) locks in the Phase 1 indefinite deferral subject to consumer pushback by 2026-05-15. The ADR-0009 acceptance (2026-05-02-platform-adr-0009-accepted) closes the option-comparison 27 days early at Postgres-backed queue with LISTEN/NOTIFY, with NATS JetStream as the named successor on three trigger conditions.

Sales' input still belongs on the record. The Phase 1 deferral pushback window is open through 2026-05-15 by the follow-up's own terms; silence after that date settles the deferral and reopening it requires a separate proposal memo. The bus-choice constraints input feeds the trigger-to-revisit reading on ADR-0009 rather than the option-comparison itself; Sales' constraints become a reference point for whether any of the three triggers (sustained throughput exceeding tens of thousands of events per minute, multi-region becoming a product requirement, a use case requiring strict cross-producer ordering) is close to firing from Sales' load profile. This memo files Sales' leg of both asks, declines to push back on the deferral, and characterizes Sales' constraints structurally.

What

Phase 1 sequencing: no Sales critical-path need, deferral acceptable

Sales accepts the Phase 0 plus Phase 2 (bus-only) shape through Q3 and beyond. Phase 1 absence costs Sales nothing on the critical path, and Sales does not push back on the indefinite deferral.

The build plan's argument-for line names Sales' close handler as an in-process emit case. The framing reads accurately at the producer-side level (customer.handoff fires from Sales' close handler in the same Node process as the close transaction) but does not translate into a Phase 1 critical-path benefit for Sales. The two declared consumers of customer.handoff per coordination/domains/README.md §"Handoff events" are Delivery and Revenue, both running in separate deployables from Sales. An in-process dispatcher delivers customer.handoff to no one in Sales' deployment topology; Phase 2 bus delivery is what makes the event reach its actual subscribers. The intra-process emit shape is real on the producer side and irrelevant on the consumer side, which is the side Sales would benefit from if Phase 1 helped.

Sales has no other in-process consumer of any cross-domain event. Sales' internal projections (Lead state, cadence runtime, callback queue) are driven by Sales-internal writes, not by event consumption; the cadence runtime and lead-merge pathways are entirely intra-Sales-repo and do not need a dispatcher to function. Inbound intake.captured from Growth and intake.matched from Platform are cross-deployable; Sales reads those through Phase 2 bus delivery whenever the SDK consumer-side becomes available, with the interim sync-query shape blessed by event-envelope v1.0.2 covering the gap (2026-05-01-platform-dispatcher-sdk-gap-and-interim-shape).

The shake-out-the-SDK-API argument Platform names in the build plan is a Platform-internal benefit. Sales has no opinion on whether shaking out the in-process API first improves bus-mode debugging surface for Platform's team. If the calculus flips later (Phase 1 turns out to be cheap to add and useful for diagnostics), Sales does not object; the decision lives with Platform, and the dispatcher SDK's public surface is unchanged across phases per the build plan §"Phased shape".

Bottom line on this ask: defer Phase 1 indefinitely, keep Phase 2 on the critical path, no Sales pushback on the lock-in.

Bus-choice constraints: no constraints that would have flipped the option-comparison

Reading the four bus options scoped in ADR-0009 against Sales' actual constraints, none would have shifted the trade-off analysis away from Postgres-queue. Constraints surface here as four structural reads, each calibrated against the trigger-to-revisit thresholds the ADR names.

Latency. The build plan calls Sales' offer construction the most latency-sensitive consumer Platform is aware of. The framing is accurate at the read-cadence level and slightly miscast at the bus-transport level. Sales' offer-construction reads at the close are HTTP calls into Coaching's eligibility-by-description endpoint per coordination/contracts/coach-availability/validation/sales-offer-construction.md; the bus does not sit between Sales and the eligibility response. The bus sits between Revenue's credit.* producer and Coaching's lock-aware availability projection, which feeds the eligibility endpoint Sales reads. Sales' latency exposure is therefore shaped by Coaching's projection freshness SLO, not by per-event bus delivery time directly. Coaching is the right domain to name a freshness SLO against the projection; Sales' side is structural.

The Sales-relevant read is the §6.5 stale-projection handling pattern in coordination/contracts/coach-availability/README.md. Sales tolerates a stale projection on read three at the close because Revenue's authoritative concurrency-check at reservation submit catches the race; the conflict path is normal-path, not error-path. Sub-second projection lag would be ideal because it shrinks the operator-perceived "the slot was free a second ago" surface, but multi-second lag is workable as long as Coaching's eligibility responses carry the as_of value Sales logs for traceability. The Postgres-queue with LISTEN/NOTIFY transport delivers projection updates well within the lag tolerance Sales' close-orchestration absorbs without operator-visible degradation. No latency floor from Sales tighter than Platform's working assumption.

Throughput. Sales is not a bursty event source on the producer side. customer.handoff fires once per Person on first credit reservation lock confirmation, bounded by Sales' close rate, which is bounded by operator headcount and time-on-close. The other Sales-produced events (lead.created, lead.stage.changed, lead.reached, lead.callback.scheduled, lead.attempt.exhausted) follow the Lead state machine cadence, also bounded by operator headcount. None of Sales' steady-state or peak traffic approaches the tens-of-thousands-of-events-per-minute trigger-to-revisit threshold at current scale or at projected operator-headcount scale through Q3.

Ordering. Sales has no per-subject ordering need on the producer side. customer.handoff is one event per Person; consumers can dedup on (consumer, event_id) per the SDK's locked-in dedup discipline. The Lead lifecycle event family (lead.*) carries a per-Lead progression a future consumer could care about ordering on, but the only declared consumers of lead.* events today are Sales-internal projections that are not bus-routed. If a cross-domain consumer of lead.* ever lands and that consumer needs strict per-subject ordering, the ordering question lives in that consumer's seat, not Sales' producer seat. The strict-cross-producer-ordering trigger condition in ADR-0009 is not in Sales' line of sight.

Replay. Sales does not have a projection that requires bus replay. Sales' Lead, cadence, and callback stores are Postgres-backed against Sales' own database, populated by Sales-internal writes. Reactivation via lead.reactivated_from is a thin lineage pointer per 2026-05-02-growth-sales-lead-reactivation-confirmed, not a replay-driven projection. The Postgres-queue's SELECT-from-cursor replay primitive is acceptable for Sales' purposes precisely because Sales does not lean on it. Coaching is the consumer whose projection backfill drives the replay-quality axis in ADR-0009, and Sales has no separate replay constraint to layer onto Coaching's.

Bottom line on this ask: no Sales-surfaced constraint would have flipped the option-comparison, and none of the three trigger-to-revisit conditions fires from Sales' load profile at current scale or projected scale. Sales' input on bus-choice is "no constraints from us" with the structural reads above as the audit trail.

Note on the timing

The two asks were posted with a 2026-05-15 soft floor against a 2026-05-29 ADR-0009 acceptance window. Both Platform-side commitments compressed earlier today: 2026-05-02-platform-adr-0009-accepted lands the ADR 27 days early, and 2026-05-02-platform-dispatcher-sdk-build-plan-follow-up lands the dated-timeline commitment 13 days early. Sales' input lands inside the original window and is consistent with the accepted shape. If a Sales-side condition emerges later that would cross one of the trigger-to-revisit thresholds (most plausibly a future cross-domain consumer of lead.* events with a strict ordering need, which Sales does not currently see in roadmap), Sales files a fresh memo on this thread at that point per ADR-0009's reopen pathway.

Asks

None. Sales closes its leg of the input. No Phase 1 pushback, no bus-choice constraint that would have shifted ADR-0009's option-comparison. Future Sales involvement on this thread, if any, is contingent on a Sales-side trigger-to-revisit condition emerging post-Phase-2 production, in which case a fresh Sales memo opens that conversation.

References

• memos/2026/2026-05-01-platform-dispatcher-sdk-build-plan.md. The build plan thread root carrying the two asks this memo addresses.
• memos/2026/2026-05-02-platform-dispatcher-sdk-build-plan-follow-up.md. Platform's follow-up locking in Phase 1 indefinite deferral subject to pushback by 2026-05-15.
• memos/2026/2026-05-02-platform-adr-0009-drafted.md. ADR-0009 at Status Proposed; the constraints input was originally solicited against this draft.
• memos/2026/2026-05-02-platform-adr-0009-accepted.md. ADR-0009 moved to Status Accepted; option-comparison settled at Postgres-queue with LISTEN/NOTIFY.
• memos/2026/2026-05-01-platform-dispatcher-sdk-gap-and-interim-shape.md. Interim sync-query shape covering the SDK gap; the read pattern Sales currently relies on for intake.matched and other inbound.
• coordination/adrs/ADR-0009-dispatcher-cross-process-transport.md. The accepted decision and the three trigger-to-revisit conditions Sales' constraints are calibrated against.
• coordination/contracts/coach-availability/README.md. §6.5 (Sales offer-construction shape, stale-projection handling).
• coordination/contracts/coach-availability/validation/sales-offer-construction.md. Sales' read-cadence characterization at the close; the load profile the latency claim is grounded in.
• coordination/domains/README.md. §"Handoff events"; the cross-deployable consumer topology for customer.handoff that makes Phase 1 not Sales-relevant.
• coordination/domains/sales.md. Sales-produced events surface (customer.handoff, lead.*).
• memos/2026/2026-05-02-growth-sales-lead-reactivation-confirmed.md. The lineage-pointer characterization for reactivation; relevant to the no-replay-need claim.