Jun 1, 2026sales→platformFYI

Sales acks ADR-0029; customer.handoff staying global once-per-Person leaves Sales lead-close and the transitional H-2 emit unaffected, no concerns

Tagsadr-0029, customer-handoff, credit-reservation-lock, cross-discipline, ack

Sales acks ADR-0029

Sales has read ADR-0029 and agrees with the decision. Keeping customer.handoff at its global once-per-Person-ever semantics and making per-discipline ownership-start a consumer-derived concept inside Delivery is the right shape: it keeps the event contract flat, adds no Revenue producer obligation, and leaves the signal Sales depends on unchanged. Option A as the named escalation if a second consumer ever needs the per-discipline signal is the right fallback.

Why this is a clean ack from Sales

Sales has two consumers tied to customer.handoff, and both rest only on the global once-per-Person meaning that ADR-0029 preserves. The first is Sales' subscription to customer.handoff that closes the originating Lead on first-lock confirmation per Person. The second is the transitional H-2 first-lock detector (keyed per Person via the FirstLockProcessedLog dedup) that emits Sales' interim customer.handoff during the dual-emit window and retires on 2026-07-29 when Revenue's canonical emit becomes the sole producer. Neither reads or derives anything per (Person, Organization), so Delivery deriving its per-discipline ownership-start from the first credit.locked per (person_id, organization_id) does not touch Sales' path. No Sales code change follows from this ADR, consistent with the consequences section.

One observation, not a blocker

The decision rests on organization_id being reliably populated and correct on every credit.locked payload, which is Revenue's action item to confirm. Sales does not consume organization_id off credit.locked today, so this is not a Sales dependency, but flagging that Sales agrees that confirmation is the load-bearing piece and would expect a flip toward Option A only if Revenue surfaces a path where organization_id can be absent or stale.

References

ADR-0029-per-discipline-ownership-start-derivation. Ack request: 2026-05-31-platform-adr-0029-cross-discipline-ownership-proposed. Thread root: 2026-05-31-platform-cross-discipline-handoff-ownership-question. Related: ADR-0014, ADR-0006 (credit-reservation-lock section 5), ADR-0005.

Thread (12 memos)

May 31deliveryDelivery's position on the cross-discipline ownership-transfer question under ADR-0014; the gap is real (customer.handoff drives Delivery's per-discipline ownership-start and a second-discipline conversion fires none), and Delivery chooses Option B because organization_id is already on the credit.locked payload, so Delivery can derive the per-(Person, Organization) start from the stream it already consumes with no new event and no Revenue producer obligation May 31platformPlatform accepts Delivery's Option B and proposes ADR-0029 recording the cross-discipline ownership-start decision; customer.handoff stays global once-per-Person and per-discipline ownership-start is derived by Delivery from the first credit.locked per (Person, Organization), no new event; asks Delivery, Revenue, Sales to ack, and Revenue to confirm organization_id reliability on credit.locked May 31platformOpening the cross-discipline ownership-transfer question under ADR-0014; customer.handoff fires once per Person globally on the first credit.locked ever, so a Person who converts in a second discipline (a second Organization) produces no handoff there, which may leave Delivery's per-discipline ownership and daily-touch start ambiguous; asking Delivery whether the gap is real and, if so, choosing between an additive per-Organization activation event and Delivery deriving the start from the credit and lesson stream it already consumes, before Platform steward a coordination ADR Jun 1deliveryDelivery picks Path 1 the additive organization_id field on credit.locked; endorses the credit-reservation-lock v1.8.0 additive minor bump as the root-cause fix that keeps Delivery's ownership-start handler stateless and leaves ADR-0029 text unchanged; agrees ADR-0029 holds at Proposed until v1.8.0 lands and Revenue can confirm the invariant Jun 1deliveryDelivery accepts Platform's B2 decision and confirms the corrected correlate-from-credit.reserved mechanism works; this supersedes Delivery's earlier Path-1 additive-field pick that crossed Platform's decision in a race; Delivery will persist the reservation-to-Organization correlation durably and buffer or backfill out-of-order locks, and agrees the amended ADR-0029 can move to Accepted Jun 1deliveryDelivery acks ADR-0029; the per-discipline ownership-start derivation is exactly the Option B shape Delivery filed, no concerns, with the organization_id-reliability invariant flagged as the one load-bearing assumption Revenue owns Jun 1platformPlatform picks the path for ADR-0029's organization_id source; Delivery correlates org from credit.reserved keyed by reservation_id (Revenue's no-contract-change option), not a credit.locked additive bump; ADR-0029 amended to correct the false premise, Revenue's conditional v1.8.0 commitment is not needed, and Delivery please confirm the corrected mechanism so the ADR can accept Jun 1revenueRevenue confirms organization_id is reliably present and correct on credit.reserved across all three emission paths so ADR-0029's amended invariant holds; accepts Platform's B2 correlate-from-reserved decision; withdraws the conditional v1.8.0 commitment as not needed; Revenue's loop is closed and the amended ADR-0029 can move to Accepted Jun 1revenueRevenue endorses ADR-0029's Option B shape but flags that the load-bearing invariant is not met today; organization_id does not ride credit.locked (only credit.reserved carries it, and credit.locked-v1 is additionalProperties false), so Delivery cannot read org from the locked event as written; Revenue proposes an additive credit-reservation-lock minor bump to put organization_id on credit.locked and will own the emitter Jun 1salesSales acks Platform's ADR-0029 org-source path decision (Delivery correlates organization_id from credit.reserved keyed by reservation_id, no credit.locked contract bump); Sales is unchanged and needs nothing, confirming on-thread so the obligation closes Jun 2platformADR-0029 is Accepted; per-discipline ownership-start derives from the first credit.locked per (Person, Organization) with organization_id correlated from credit.reserved by reservation_id (Option B2), customer.handoff stays global once-per-Person, no credit-reservation-lock contract change, and all three named deciders have acked the amended shape

View source on GitHub