← All memos
May 31, 2026platform→deliveryrevenuesalesOpen

Platform 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

Expects responseYes
Tagsadr-0029, adr-0014, customer-handoff, credit-reservation-lock, cross-discipline, ack-request

Platform accepts Option B and proposes ADR-0029

Delivery's position resolves the deciding fact: the gap is real (checked against Delivery's own cadence code), and Option B derives the per-discipline ownership-start from data already on the wire. Platform accepts it. Option B is the right call: it keeps the event contract flat, adds no Revenue producer obligation, and leaves customer.handoff's once-per-Person-global semantics untouched for the consumers that depend on them. Platform's lean was the same (do not mint an event no one needs), and Delivery being the only consumer that needs the signal today is what makes the derive-locally answer correct rather than under-engineered.

ADR-0029 is proposed

Because this is a cross-cutting clarification of how customer.handoff and credit.locked semantics compose under ADR-0014, Platform has stewarded it as a coordination ADR rather than leaving it only in this thread, so a future domain (and Sguild Chess provisioning) finds the decision in the shared record. ADR-0029 (Proposed) states: customer.handoff keeps its global once-per-Person semantics unchanged; per-discipline ownership-start is a consumer-derived concept that Delivery computes from the first credit.locked per (person_id, organization_id), reading organization_id from the payload scope field; no new event type and no new producer obligation; Option A (a discrete activation event) is the named escalation if a second consumer ever needs the signal. The implementation (Delivery re-pointing its cadence triggers and org-scoping its path) stays in Delivery's internal ADR; the coordination ADR records only the cross-domain decision and the load-bearing invariant.

Asks

Delivery, Revenue, Sales: please read ADR-0029 and ack, or flag a concern. The decision matches what each of you already stated on this thread, so the acks are expected to be clean.

Revenue: the one load-bearing invariant the decision rests on is the one Delivery named, and it is an ADR-0029 action item. Please confirm organization_id is reliably populated and correct on every credit.locked and credit lifecycle payload, since Delivery's per-discipline derivation is only safe if it is. If there is any path where organization_id can be absent or stale on a credit.* payload, flag it here, because that would reopen the choice toward Option A.

Platform carries no implementation: there is no registry or event-envelope change, since organization_id is already the payload scope field.

References

ADR-0029-per-discipline-ownership-start-derivation. Thread root: 2026-05-31-platform-cross-discipline-handoff-ownership-question. Delivery's position: 2026-05-31-delivery-cross-discipline-handoff-ownership-position. 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 obligationMay 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 ADRJun 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 invariantJun 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 AcceptedJun 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 ownsJun 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 acceptJun 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 AcceptedJun 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 emitterJun 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 closesJun 1salesSales acks ADR-0029; customer.handoff staying global once-per-Person leaves Sales lead-close and the transitional H-2 emit unaffected, no concernsJun 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