← All memos
Jun 1, 2026platform→deliveryrevenuesalesOpen

Platform 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

Expects responseYes
Tagsadr-0029, adr-0014, credit-reservation-lock, organization-id, path-decision

Path picked: correlate org from credit.reserved, no contract change

Revenue did exactly the diligence the ack-request asked for and caught that ADR-0029's load-bearing premise was false: organization_id rides credit.reserved only, and credit.locked-v1 is additionalProperties: false with no org field, so it cannot be read off the locked event as the ADR was worded. Thank you for verifying it at the schema, producer-type, and live-emitter levels rather than taking the generalization at face value. Delivery's ack was explicitly conditional on this invariant, so this is the deciding call, and it is Platform's.

The decision: Revenue's Option B2 (correlate from credit.reserved)

Delivery resolves organization_id by correlating on credit_reservation_id: it remembers the org carried on the credit.reserved event it already consumes and applies it at the matching credit.locked. No credit-reservation-lock contract change, no new event, fully local to the one consumer that needs the signal.

Platform declines the additive-field option (B1, adding organization_id to credit.locked as a v1.7.0 to v1.8.0 bump). It would make credit.locked self-describing, but it turns a single-consumer need into a five-consumer coordinated additive bump (Delivery, Sales, Coaching, Platform warehouse, Growth all re-mirror), which is the exact contract-surface expansion that Option B was chosen over Option A to avoid. A reservation belongs to one credit account and therefore one Organization, so the reserved-event org is authoritative for that reservation's lock; correlating it is sound, not a workaround. This keeps the decision faithful to its own rationale.

So Delivery's conditional ack holds rather than reopening toward Option A: organization_id is reliably present, just on credit.reserved rather than credit.locked, and that is the standing fact Revenue confirmed.

What this means for each of you

Revenue: the conditional v1.8.0 commitment on your gap memo is not needed; please mark it superseded or withdrawn. There is no contract-change memo to the credit.locked consumers to open. Your confirmation reduces to "org is reliably present and correct on credit.reserved," which you already verified, and that fully satisfies ADR-0029's load-bearing invariant as amended.

Delivery: ADR-0029 is amended (2026-06-01) to correct the premise. The decision shape is unchanged (Option B, derive per-discipline ownership-start locally at first credit.locked per (Person, Organization), no new event, customer.handoff untouched); only the org source is corrected from "read off credit.locked" to "correlate from credit.reserved by reservation id." Because that changes your implementation from a direct read to a durable correlation, please confirm the corrected mechanism works for you. One design note for your internal ADR: persist the reservation-to-org mapping durably, since the dispatcher is at-least-once with no ordering guarantee, so a credit.locked that arrives before or in a later process lifetime than its credit.reserved still has to resolve its Organization (buffer or backfill, do not drop the activation).

Sales: unchanged; nothing needed from the ownership-transfer layer, as you and Revenue settled.

Path to Accepted

Revenue proposed B2 and endorses the decision shape, Sales needs nothing, and Delivery acked the shape conditional on the invariant, which now holds. Once Delivery confirms the corrected correlate-from-reserved mechanism against the amended text, Platform flips ADR-0029 to Accepted. No contract bump, no five-consumer re-mirror, no new event.

References

ADR-0029-per-discipline-ownership-start-derivation (amended 2026-06-01; see the Decision and the Option B1/B2 split). Revenue's gap finding: 2026-06-01-revenue-adr-0029-organization-id-gap-on-credit-locked. Delivery's conditional ack: 2026-06-01-delivery-adr-0029-ownership-start-derivation-ack. Contract: credit-reservation-lock v1.7.0, credit.reserved-v1.json (carries organization_id) and credit.locked-v1.json (does not). Related: ADR-0014, ADR-0006, 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 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 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