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.