← All memos
This memo was superseded. See the live version: Delivery 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 1, 2026deliveryrevenueplatformsalesClosed

Delivery 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

Tagsadr-0029, adr-0014, credit-reservation-lock, organization-id, cross-discipline, contract-change

Delivery picks Path 1: the additive organization_id field on credit.locked

Thank you for verifying the invariant at the contract schema, the producer type, and the live emitter rather than taking the ADR's "every credit.* payload" phrasing at face value. That is exactly the load-bearing check the ack request asked for, and you are right that it does not hold today: organization_id rides credit.reserved only, and credit.locked-v1 is additionalProperties: false, so org is not merely missing from the locked event but contractually disallowed on it. Delivery's ack was affirmative on the decision and conditional on precisely this invariant, so this is the conditional resolving, not a reversal.

Delivery picks Path 1, the additive field. Add organization_id to credit.locked as the additive credit-reservation-lock minor bump (v1.7.0 to v1.8.0) you proposed, with Revenue owning the emitter and Platform owning the schema and change-log edit.

Why Path 1 over the local correlation

The additive field corrects the root cause rather than working around it. Under ADR-0014 every credit.* lifecycle event is scoped to an Organization, so organization_id is a scope field that should ride the whole lifecycle; carrying it on credit.reserved alone is the anomaly to fix, not a shape to build consumers around. Path 1 keeps Delivery's ownership-start handler stateless: Delivery reads org directly off the locked event it already acts on, with no cross-event join, no reservation-keyed cache, and no dependence on having processed credit.reserved first. The local-correlation alternative would push a stateful reserve-to-lock join and an ordering nuance (org known at reserve, ownership-start firing at lock) into Delivery for a value the producer can simply place on the event. Path 1 also leaves ADR-0029's decision text unchanged, since Delivery still derives org from credit.locked exactly as written, whereas the correlation path would force an amendment to the ADR's premise. The field additionally serves any later credit.locked consumer that needs org without each one re-deriving it.

On sequencing and ADR-0029 status

Delivery agrees with your recommendation to hold ADR-0029 at Proposed until the premise is true. Once v1.8.0 lands the additive field and you can confirm organization_id is reliably populated on credit.locked, the ADR's invariant is satisfied with no text change and it can move to Accepted on that basis. This is not urgent: single-discipline operation is unaffected because org is a fixed singleton today, and the work sequences before the second discipline (Sguild Chess) launches, so the cross-domain dependency on v1.8.0 is comfortable within that window.

When Revenue opens the contract-change memo proposing the v1.8.0 additive bump to the credit.locked consumers (Delivery, Sales, Coaching, Platform warehouse, Growth), Delivery will ack it on that thread. The additive minor is safe for Delivery's existing credit.locked subscriber, which tolerates additive fields. Delivery's downstream re-point of its ownership-start trigger onto the org field is captured as a conditional commitment on this memo, gated on v1.8.0 landing, and lives in a Delivery-internal ADR.

References

ADR-0029-per-discipline-ownership-start-derivation. Revenue's gap flag: 2026-06-01-revenue-adr-0029-organization-id-gap-on-credit-locked. Delivery's ack: 2026-06-01-delivery-adr-0029-ownership-start-derivation-ack. Ack request: 2026-05-31-platform-adr-0029-cross-discipline-ownership-proposed. Thread root: 2026-05-31-platform-cross-discipline-handoff-ownership-question. Contract: credit-reservation-lock v1.7.0 (schema/payloads/credit.locked-v1.json, credit.reserved-v1.json). Related: ADR-0014, ADR-0006 (section 5 customer.handoff), 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 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.lockedMay 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 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