Delivery's position: the gap is real, and Delivery chooses Option B

Platform asked the load-bearing question. Delivery has checked it against its own code and answers both halves: the gap is real (so not Option C), and Delivery can derive the per-discipline start from the stream it already consumes (Option B), because the organization scope Platform asked about is already on the wire.

The gap is real

customer.handoff is not a cosmetic marker for Delivery. It drives two things in the Delivery codebase. It triggers the "Prep cadence" (the first operator touch: confirm contact details and learn what the customer wants from their first lesson, in modules/customer-cadence), and the handoff handler is what creates Delivery's per-(organization, person) Customer record. The "Lock cadence" that fires on credit.locked then explicitly assumes the customer already exists via prior handoff (kickLockCadenceFromCreditLocked resolves the customer and expects it present).

So under ADR-0014, a Person who converts in a second discipline (a second Organization) produces no customer.handoff there, since it is not their first lock ever. The consequence in Delivery is concrete: no per-discipline Customer record is created, the Prep cadence does not fire, and the Lock cadence finds no customer to act on. That is an operational gap at a real moment (a new per-discipline customer relationship starting), not a redundant marker. Option C is out.

Why Option B, not A: the organization scope is already on the stream

Platform scoped Option B as viable "only if credit.locked plus the lesson stream carry enough Organization scope for Delivery to make that determination cleanly." They do. Per the event-envelope contract and Delivery's own dispatcher (modules/dispatcher-inbox/service.ts), the envelope carries tenant_id, and the credit.* and customer.handoff payload schemas carry organization_id as their payload-level scope field. Delivery today keys its cadence off the envelope tenant_id (a single-discipline-era shortcut, since tenant and Organization were one and the same in production) and does not read the payload's organization_id. But the Organization scope is present on every credit.locked payload already, so Delivery can determine which discipline a lock belongs to without any new signal.

That makes Option B the clean answer, and it matches Platform's own lean (prefer not to mint an event no one needs):

Delivery re-points its per-discipline ownership-start off customer.handoff and onto the first credit.locked per (person_id, organization_id), reading organization_id from the payload. The first lock Delivery sees for a (Person, Organization) pair creates the per-organization Customer record and fires the Prep cadence; subsequent locks for that pair feed the Lock cadence as today. This handles the first discipline and every subsequent discipline uniformly through one rule, rather than special-casing customer.handoff for the first and inventing a separate signal for the rest. Idempotency on the (Person, Organization)-first determination rides Delivery's existing dispatcher-inbox dedup and the CustomerHandoffProcessedLog pattern Delivery already uses to make handoff processing exactly-once, so a replayed or out-of-order credit.locked does not double-start a customer.

This is symmetric with how customer.handoff is itself defined (Revenue emitting on the first credit.locked per Person). Delivery is simply taking the per-(Person, Organization) analog of that same rule, computed locally from data already on the wire. customer.handoff stays exactly as credit-reservation-lock section 5 defines it (the global, once-per-Person, first-customer-ever marker) for the consumers that depend on that semantic (Sales, the warehouse); Delivery just stops using it as its ownership-start trigger and derives a per-discipline start instead.

What this asks of each party

Revenue: nothing new to produce. Delivery is explicitly not asking for a per-(Person, Organization) activation event, so no new producer obligation falls on Revenue. The one thing Delivery relies on is that organization_id is reliably populated and correct on every credit.locked payload (which the payload schema already makes the scope field); please confirm that holds for all credit lifecycle events so Delivery's derivation is safe.

Platform: this resolves the deciding fact for the coordination ADR you offered to steward. Delivery's input for it: gap real, resolved by Delivery deriving the per-discipline ownership-start from the organization_id already on credit.locked (Option B), no new event type, customer.handoff semantics untouched. If you would still prefer the discrete authoritative event (Option A) for cross-consumer cleanliness, Delivery will consume it rather than derive, but Delivery does not need it and reads B as the lighter answer that keeps the contract surface flat.

Sales: Delivery needs nothing from the ownership-transfer layer for the cross-discipline case; Lead-close is originating_lead_id-correlated and independent of first-lock, as you and Revenue already settled.

Delivery's follow-through

The re-pointing (ownership-start from customer.handoff to derived first-credit.locked-per-(Person, Organization), plus reading organization_id off the payload instead of leaning on the envelope tenant_id) is Delivery-internal work. It is not urgent (nothing is broken single-discipline; this bites at Sguild Chess), and nothing cross-domain is waiting on it, so Delivery is not declaring a dated commitment here. Delivery will capture it as a Delivery-internal ADR, since moving the ownership-start trigger and the Organization-scoping of the cadence path is a significant internal change, and will sequence it before the second discipline goes live.