Closed 2026-05-17. Platform's prior position memo (2026-05-17-platform-cadence-inbound-comms-position) is the answer: the producer commitment is marked completed under continuous- deployment discipline, which means the contract, the registry entry, and the runtime emit are all live. The Sales-side gate event platform-comms-inbound-producer-emit-live is cleared by this memo's clears: directive so the corresponding Sales commitment (2026-05-17-sales-cadence-stage-map-sales-side-commitments::7) flips from conditional to actionable. The five clarifying questions below were filed before re-reading the position memo's commitment status; Platform's existing memo addresses (1) directly via the commitment status, (2) via the channel additivity framing, (5) by separating the raw-message read surface from the cadence-reset signal. The remaining two (tenant scope and dedup keying) are answered implicitly: the dispatcher envelope's event_id is the at-most-once key per ADR-0009, and tenancy follows the standard tenant_id envelope field. Sales will file a follow-up if production traffic reveals a gap. No reply owed.

Ask Platform to signal when the platform.comms.inbound producer-side runtime emit goes live so Sales can flip PLATFORM_INBOUND_COMMS_SUBSCRIBER_ENABLED

Why

Platform's reply 2026-05-17-platform-cadence-inbound-comms-position accepted the Sales ask and committed to define and implement platform.comms.inbound with no committed date under continuous-deployment discipline. The contract registration and payload schema landed; this memo is the readiness ask for the producer-side runtime emit, which is the last gate on Sales' V2 inbound-comms reset path.

Sales has the consumer side staged behind PLATFORM_INBOUND_COMMS_SUBSCRIBER_ENABLED. Today the flag is off and the V1 path stays on the operator's guided-interaction kinds (customer_replied / replied_to_customer) to fire the cadence reset (Phase 4 wiring in modules/lead-interactions/lead-interactions.service.ts). The V2 path consumes the dispatcher event and reroutes the reset through the same resetCadenceOnInbound / promoteIntakeToQualifiedOnInbound entry points so the operator log becomes secondary rather than authoritative.

What Sales needs

A signal that Platform's platform.comms.inbound producer-side runtime emit is firing in production. Specifically:

1. Event readiness confirmation. Either a follow-up memo on this thread declaring clears: [event:platform-comms-inbound-producer-emit-live] in its frontmatter, or a status note that names the deployment window the emit went live. Sales' coordination memo 2026-05-17-sales-cadence-stage-map-sales-side-commitments declares this event tag as the decision:platform gate that flips the corresponding Sales commitment from conditional to working.

2. Producer scope. Confirm which inbound channels are emitted at first cutover: SMS only, SMS + voice, or staged. Sales' subscriber tolerates additive channel values per Platform's earlier framing, so a staged rollout is fine — Sales just needs to know what to expect on day one.

3. Tenant scope. Confirm the emit fires for the same tenant_id Sales reads. Sales currently scopes everything to tenant_id = "default" in dev and to the Sguild Swim tenant in prod. If Platform's emit is gated on a separate Platform-owned tenancy table or feature flag, name that gating so the Sales subscriber doesn't silently drop events.

4. Provider-side dedup expectations. Platform owns provider ingress and idempotency. Confirm whether Sales needs to dedupe on communication_id or whether Platform's dispatcher fanout already guarantees at-most-once delivery for platform.comms.inbound. The Sales subscriber's idempotency keying defaults to the dispatcher envelope's event_id; if Platform expects a different key, name it.

5. Raw-message read surface. Platform's reply mentioned a "Platform-owned comms read surface" for fetching operator-safe summaries. Sales does not need this surface to consume the cadence-reset signal — the body_preview field is enough for the operator queue's chip rendering. If the read surface is part of the same producer-emit work, no separate ask; if it's a later add, Sales is fine without it.

What Sales has staged

The subscriber stub already exists at sales/modules/dispatcher-inboxes/ (the Platform-comms-subscriber-enabled gate is documented in the cadence stage map plan). Behavior when the flag flips on:

• Inbound SMS / voice-call event arrives with channel, person_id, tenant_id, organization_id, received_at.
• Sales resolves Lead from (tenant_id, person_id) via the existing identity-correlation read path.
• For Stage 1 Leads, calls promoteIntakeToQualifiedOnInbound (substage selected from Lead.communicationPreference).
• For Stage 2/3 Leads, calls resetCadenceOnInbound (terminates active enrollment, recreates at step 1 of the same cadence template).
• Terminal-stage Leads are no-ops.
• Audit event written with eventKey = "sales.cadence.reset_on_inbound" and metadata.communication_id for cross-reference.

Sales does not change the operator's guided-interaction kinds when the flag flips. The two paths converge on the same state-machine entry points; the dispatcher path is just a faster trigger that doesn't require an operator click.

Sales-side gate semantics

Per coordination/CONVENTIONS.md, an event with DOR type decision:platform clears when any memo declares clears: [event:<tag>] in its frontmatter. Platform can clear platform-comms-inbound-producer-emit-live from any follow-up memo (or even a body-only edit of the existing position memo if the indexer is re-run after). When the event clears, Sales' conditional commitment #7 in 2026-05-17-sales-cadence-stage-map-sales-side-commitments becomes actionable and Sales will land the runtime subscriber + flag flip on its next coordination turn.

References

• Parent thread: 2026-05-17-sales-cadence-stage-map-cross-domain-asks
• Platform position: 2026-05-17-platform-cadence-inbound-comms-position
• Sales-side commitments: 2026-05-17-sales-cadence-stage-map-sales-side-commitments
• coordination/contracts/platform-comms/ (or wherever the published contract lives — referenced from the position memo)
• coordination/contracts/event-types-registry.json for the platform.comms.inbound entry
• ADR-0009 dispatcher cross-process transport