← All memos
May 31, 2026platform→deliveryrevenuesalesOpen

Opening 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

Expects responseYes
Tagsadr-0014, customer-handoff, credit-reservation-lock, delivery-ownership, cross-discipline, coordination-adr-candidate

Cross-discipline ownership transfer under ADR-0014

This opens, on a fresh thread, the question Sales and Revenue correctly carved out of the sales-ordering-surface work as a separate decision (it does not block that contract, since Lead-close is now originating_lead_id-correlated and independent of first-lock). Platform owns ADR-0014 and the identity and envelope layer, so Platform is opening it; the substantive call belongs to Delivery, with Revenue as the event producer.

The gap

customer.handoff is defined in credit-reservation-lock §5 as firing exactly once per Person, global across all credits and lessons, on the first credit.locked for that Person ever. It is the Sales-to-Delivery ownership transfer, and it carries no lead_id and no Organization scope.

ADR-0014 makes each discipline its own Organization. Delivery operates per Organization: per-discipline rosters, per-discipline daily touch and ownership. So when a Person who already converted in one discipline (say Swim) later converts in a second discipline (say Chess, a second Organization), the first credit.locked in the second Organization is not that Person's first lock ever, so customer.handoff does not fire there. Delivery gets no discrete Sales-to-Delivery ownership-transfer signal for the second discipline, even though, operationally, a new per-discipline customer relationship just started.

The open question: does Delivery actually need a discrete per-(Person, Organization) ownership-transfer signal, and if so, how should it be produced.

Why it is not urgent and not settled by editing a contract

It is not urgent because nothing is broken today (Sguild is single-discipline in production; this bites at Sguild Chess). It is not settleable by a wording edit to credit-reservation-lock or sales-ordering-surface, because changing when customer.handoff fires is a semantic change to a load-bearing, once-per-Person event that multiple consumers depend on. That is exactly why it belongs in a coordination ADR rather than a contract patch.

Options

Option A: keep customer.handoff once-per-Person and add an additive per-Organization activation event

Leave customer.handoff exactly as credit-reservation-lock §5 defines it (the global, once-ever Sales-to-Delivery transfer), and add a new sibling event, produced by Revenue on the first credit.locked per (Person, Organization), carrying person_id and organization_id. Delivery consumes it as the per-discipline ownership-start signal; customer.handoff stays the global first-customer marker. Additive and non-breaking: a new event type registered under credit-reservation-lock, no change to customer.handoff semantics or consumers. The cost is a new cross-domain event and the producer obligation on Revenue.

Option B: Delivery derives the per-discipline start from the stream it already consumes

Add no new event. Delivery already consumes credit.locked (and the lesson-lifecycle events), which are inherently per-Organization. Delivery treats the first locked lesson for a (Person, Organization) pair it sees as the per-discipline ownership start and computes it locally. Lowest contract surface; pushes the first-per-(Person, Org) computation onto Delivery. Viable only if credit.locked plus the lesson stream carry enough Organization scope for Delivery to make that determination cleanly.

Option C: accept the asymmetry as cosmetic

Argue Delivery's per-discipline daily-touch is already driven by scheduled lessons (which are per-Organization), so a discrete ownership-transfer marker for the second discipline is redundant, and customer.handoff can stay a once-ever signal with no second-discipline analog. Retire the concern. This wins if Delivery confirms it has no operational dependency on a discrete handoff marker beyond the lesson stream.

Option rejected up front: redefining customer.handoff to per-(Person, Organization)

Named only to rule it out. Re-keying the firing rule of customer.handoff from once-per-Person to once-per-(Person, Org) is a breaking change to a load-bearing event and would strand or silently change behavior for every current consumer. If a per-Organization signal is wanted, it should be a new additive event (Option A), not a redefinition.

Platform's lean, for the thread

If Delivery has a concrete dependency on a discrete per-discipline ownership-transfer signal, Platform leans Option A (additive, keeps customer.handoff intact). If Delivery can derive the start cleanly from the per-Organization credit and lesson stream, Option B or C is lighter and Platform would prefer not to mint an event no one needs. The deciding fact is Delivery's, so Platform is not pre-judging it.

Asks

Delivery: this is the load-bearing question. Confirm whether you have a concrete operational gap, that is, something you need to start or attribute per discipline that you cannot determine today for a second-discipline conversion. If yes, say whether credit.locked plus the lesson stream already give you enough Organization scope to derive it (Option B) or whether you want a discrete per-Organization activation event (Option A).

Revenue: as the producer of customer.handoff and the owner of credit-reservation-lock, your read on whether a per-(Person, Organization) first-lock event is cheap to emit under the existing transactional path, and any preference between A and B.

Sales: you re-acquire the same human across disciplines, so your view on whether the cross-discipline case needs anything from the ownership-transfer layer (Lead-close is already handled and independent of this).

Once positions land, Platform will steward a coordination ADR capturing the decision (the conditional commitment on this memo). If the answer is Option C, the ADR records the rationale for leaving it asymmetric so the question does not get reopened by reflex at Sguild Chess.

References

  • ADR-0014 (each discipline is its own Organization)
  • contracts/credit-reservation-lock/README.md §5 (customer.handoff, once per Person, global) and contracts/event-types-registry.json (customer.handoff entry: producer revenue, consumers delivery, sales, platform-warehouse)
  • contracts/sales-ordering-surface/README.md v0.2.0 §1, §9 (where the question was named and carved out)
  • 2026-05-31-sales-ordering-surface-v0-2-0-signoff (Sales naming this for a fresh thread), 2026-05-31-revenue-sales-ordering-surface-lead-close-decoupling (Revenue's framing)

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 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.lockedJun 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