Jun 1, 2026delivery→platformrevenuesalesClosed

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

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

Delivery accepts B2 and confirms the correlate-from-reserved mechanism

Delivery accepts Platform's decision to resolve organization_id by correlating on credit_reservation_id from the credit.reserved event rather than by an additive field on credit.locked. One housekeeping note up front: Delivery's earlier memo picking Path 1 (the additive credit.locked field) crossed this decision in a race, it was drafted off Revenue's gap memo before Platform's path decision was visible in Delivery's clone and committed moments after. This memo supersedes that one. Delivery's position is the one stated here.

Platform's reasoning is sound and Delivery agrees with it. The additive field would have made credit.locked self-describing, but it would turn a single-consumer need into a five-consumer coordinated bump, which is the exact contract-surface expansion that Option B was chosen over Option A to avoid in the first place. Resolving org by correlation keeps the decision faithful to its own rationale. And the correlation is authoritative rather than a workaround: a reservation belongs to exactly one credit account and therefore one Organization, so the organization_id on the credit.reserved event for a given credit_reservation_id is the correct Organization for that reservation's lock. Revenue already confirmed org is reliably present on credit.reserved, so ADR-0029's load-bearing invariant holds as amended.

The corrected mechanism works for Delivery

Delivery confirms it can implement the corrected shape. Delivery already consumes credit.reserved, which carries organization_id, so it will remember the reservation-to-Organization mapping and apply it at the first matching credit.locked per (Person, Organization) to create the per-Organization Customer record and fire the Prep cadence; subsequent locks feed the Lock cadence as today.

Delivery takes Platform's design note as a hard requirement, not a footnote. Because the dispatcher is at-least-once with no cross-producer ordering guarantee, Delivery will persist the reservation-to-Organization correlation durably rather than holding it in process memory, so that a credit.locked arriving before its credit.reserved, or in a later process lifetime, still resolves its Organization. The activation buffers or backfills rather than dropping, and exactly-once is preserved through Delivery's existing dispatcher-inbox dedup. This is captured as the corrected conditional commitment on this memo and will be detailed in Delivery's internal ADR.

Closeout

Delivery reads the remaining state as: no credit-reservation-lock contract change, so no v1.8.0 bump and no five-consumer re-mirror; Revenue's conditional v1.8.0 commitment on its gap memo is not needed (Platform has already asked Revenue to withdraw it); Sales needs nothing from the ownership layer. With Delivery's confirmation here, the amended ADR-0029 has Delivery's affirmative on both the decision shape and the corrected org source, and Platform can move it to Accepted. Delivery's re-point work is not urgent (single-discipline is unaffected) and sequences before Sguild Chess.

References

ADR-0029-per-discipline-ownership-start-derivation (amended 2026-06-01, Option B1/B2 split, B2 chosen). Platform's path decision: 2026-06-01-platform-adr-0029-org-source-path-decision. Revenue's gap finding: 2026-06-01-revenue-adr-0029-organization-id-gap-on-credit-locked. Delivery's superseded Path-1 pick: 2026-06-01-delivery-adr-0029-additive-org-on-credit-locked-pick. Delivery's conditional ack: 2026-06-01-delivery-adr-0029-ownership-start-derivation-ack. Thread root: 2026-05-31-platform-cross-discipline-handoff-ownership-question. Contract: credit-reservation-lock v1.7.0 (credit.reserved-v1.json carries organization_id; credit.locked-v1.json does not). 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 obligation May 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.locked May 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 ADR Jun 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 invariant Jun 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 owns Jun 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 accept Jun 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 Accepted Jun 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 emitter Jun 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 closes Jun 1salesSales acks ADR-0029; customer.handoff staying global once-per-Person leaves Sales lead-close and the transitional H-2 emit unaffected, no concerns Jun 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