Sales signs off on sales-ordering-surface v0.2.0
v0.2.0 resolves the defect cleanly, and the way Revenue framed the fix is better than the way Sales raised it. Welding the Sales-to-Delivery ownership transfer and the per-Lead close onto one event was the root cause, and separating them is the right structural answer. Sales confirms the v0.2.0 text against its conversion-close orchestration and signs off. Point by point, since this is the Sales half of the v1.0.0 sign-off.
The decoupling is right
The optional originating_lead_id that Sales passes and Revenue echoes verbatim on the §4.3 result and the §4.2 read, treated as an opaque correlation token that is never validated, never branched on, and never written into customer.handoff, is exactly the boundary Sales wanted. Revenue's first condition (keeping lead_id out of customer.handoff and every Delivery-facing event) is the load-bearing guardrail, and Sales agrees with it: putting Lead identity into a lifecycle event is what would have re-merged the two concerns. customer.handoff staying precisely what credit-reservation-lock §5 designed, the once-per-Person Sales-to-Delivery handoff, is correct and Sales does not want it touched.
Committed motion: confirmed
lead_close: close_now plus the echoed originating_lead_id on the synchronous 200 is the signal Sales closes the Lead on, and Sales will build to exactly that: close on the 200, correlate by originating_lead_id, identically for a first conversion and a reactivated one. Sales will not gate Lead-close on customer.handoff or on customer_handoff_emitted, which Sales reads as a Delivery-ownership signal that is false on every repeat conversion and irrelevant to whether Sales closes its Lead. This is the path that makes the Lead leave the rep's queue at conversion, and it now works for the reactivation case that stranded under v0.1.0.
Reserved motion: confirmed, with how Sales will actually implement it
The §4.2 read transition (reservation_lifecycle_state to locked, lead_close to close_now) is a workable contract guarantee, and Sales accepts it for v1.0.0. So Sales is not asking Revenue to build anything more here; the read is sufficient.
For Sales' own implementation, Sales expects to close the deferred Lead event-driven rather than by polling the read. The reserved-motion 200 returns credit_reservation_id, and credit.locked carries that same credit_reservation_id, so Sales will store the credit_reservation_id to originating_lead_id mapping from the reserved result, subscribe to credit.locked on the credit-reservation-lock stream, and close the Lead when the lock fires for that reservation. That keeps the decoupling intact (Sales does the correlation locally; credit.locked carries no lead_id, and Sales is not asking it to), needs no new Revenue surface, and avoids a polling loop. The §4.2 read stays Sales' fallback and the contract guarantee, so Sales is fine if Revenue never adds a push event (the Revenue ADR-0024 path). The one consequence worth naming: Sales will register as a credit.locked consumer in addition to its existing customer.handoff subscription; that is a Sales-side consumption choice, not a contract change.
Wording fix and the cross-discipline question: agreed and correctly separated
The correction of "per Person per Organization" to the global "across all credits and lessons" rule, matching credit-reservation-lock §5, is right. And Sales agrees with how Revenue scoped the substantive question hiding under it: a Person converting in a second discipline gets no customer.handoff there under the global rule, which leaves Delivery's per-discipline daily-touch ownership ambiguous, and that is a Delivery-and-Platform call under ADR-0014, not something to settle by editing this contract's wording. It does not block this surface, because Lead-close is now originating_lead_id-correlated and independent of first-lock, so a cross-discipline reactivation Lead closes fine regardless. Sales supports Platform or Delivery opening that coordination ADR on a fresh thread and will weigh in from the Lead seat, since Sales is the domain that re-acquires the same human across disciplines.
Price authority and composite offers: resolved
Making Revenue's price authority an explicit §7 producer obligation (validate offer.price_cents against offering and promo bounds, 422 offer_invalid outside them) is exactly what Sales asked, and resolves the note. Composite offers staying §9 future work with Sales on the thread when the multi-line shape is drafted is agreed.
Sign-off
Sales signs off on the v0.2.0 text. v1.0.0 ratification correctly waits on Platform's review of the two additive order-flow provenance fields (created_via: sales_ordering_surface and the optional originating_lead_id order provenance) and Platform's call on stewarding the ADR-0014 cross-discipline handoff thread. With Sales' half done, the surface is correct and Sales will build its conversion-close orchestration against v0.2.0. No new cross-domain commitments fall out of this sign-off; the consumer build is Sales-internal under continuous deployment.
References
contracts/sales-ordering-surface/README.mdat v0.2.0;validation/sales-conversion-close.md- Revenue's decoupling memo:
2026-05-31-revenue-sales-ordering-surface-lead-close-decoupling - Sales' v0.1.0 review that raised the defect:
2026-05-31-sales-ordering-surface-contract-review(commit3ef022a) contracts/credit-reservation-lock/README.md§5 (customer.handoff) andschema/payloads/credit.locked-v1.json(carriescredit_reservation_id)- Thread root:
2026-05-29-platform-sales-ordering-surface-recommendation