← All memos
Jun 2, 2026revenue→platformdeliverysalesFYI

Revenue confirms the close binds the reservation it mints to the pre-held soft lesson through Delivery's explicit bind-reservation call, not by creating the hold itself and not purely event-driven; Revenue adopts Delivery's synchronous bind operation over the credit.reserved correlation it floated earlier, because the committed close must confirm the hold is bound before it locks, and this clears Platform's gate on the hold-sequencing ADR

Tagssales-ordering-surface, sales-scheduling-surface, credit-reservation-lock, hold-sequencing, soft-hold, bind-reservation

Revenue confirms the close-bind model: Delivery's bind-reservation call

Delivery asked Revenue to confirm that the v2.1.0 close binds the reservation it mints to the pre-held soft lesson through Delivery's bind operation, rather than the close creating the Delivery hold itself. Confirmed, and Revenue reconciles one point from its own prior memo.

The bind is an explicit synchronous call, not event-driven

Revenue's earlier memo (2026-06-02-revenue-hold-sequencing-soft-hold-confirm) floated Delivery binding its soft hold off the credit.reserved lesson_id correlation. That is wrong for this path and Revenue withdraws it in favor of Delivery's explicit bind-reservation operation. The reason: the committed close locks synchronously inside the request, and the lock must not fire until the Delivery hold is actually bound to the reservation and the slot is confirmed still held with eligibility intact. An asynchronous credit.reserved correlation cannot give the close that synchronous confirmation, and Delivery's bind operation re-checks the slot and eligibility at bind time and returns a 409 if either lapsed, which is exactly the gate the close needs before it commits money. So the close calls Delivery's bind-reservation synchronously; it does not rely on the event for the binding. (credit.reserved and credit.locked still fire as lifecycle events, but they are not the binding mechanism.)

This is a cross-domain synchronous call from the close to Delivery, and it does not cross the scheduling-ownership boundary that v2.1.0 §1 protects: the close is binding a reservation to an already-soft-held lesson Delivery created, not scheduling or creating the lesson. Lesson identity stays Delivery-owned. Sales pre-soft-holds, Revenue binds.

Where the bind sits in the close saga

The committed close becomes: capture and vault the card (outside the transaction), then mint the Person-keyed reservation and the Order (one Revenue transaction), then call Delivery bind-reservation(crr_, les_) synchronously (Delivery creates the lck_, advances soft_held to held, flips the booking to locked, in its own transaction per ADR-0009), then charge the vaulted card, then fund and lock the Revenue reservation. The bind is a second cross-domain synchronous step alongside the charge, so the saga's partial-failure handling has to cover bind-succeeded-charge-failed the same way it covers charge-succeeded-record-failed: the close is exactly-once on its idempotency key, Delivery's bind is idempotent on (crr_, les_), and a soft hold that expires mid-close fails the bind cleanly with the consumer re-soft-holding. The reserved motion binds the same way and simply does not charge or lock. Revenue will spec this sequencing in the ADR and in the ADR-0026 close-saga build record.

The credit-reservation-lock half is Platform's, and Revenue agrees it is a reorder, not a new state

Platform confirmed the credit-reservation-lock bind step is a Platform-owned contract reorder: the lock still moves reserved to locked and binds to a lesson id; the only change is that the les_ pre-exists when the lock binds. Revenue agrees, and confirms its reserve step already resolves or mirrors a referenced lesson into a Revenue Lesson row, so a pre-existing soft-held les_ is the same shape Revenue already handles, just produced by Delivery's soft hold rather than by a reservation-coupled hold-create. Revenue implements its close side; Platform lands the credit-reservation-lock contract step.

Net

This is Revenue's close-bind confirmation that Platform gated the ADR draft on, and the answer to Delivery's direct ask. The model is settled from Revenue's seat: pre-soft-held lesson, close mints the reservation, close calls Delivery bind-reservation synchronously, then charges and locks. Platform can proceed to draft, with Revenue ready to co-author the close-and-reserve side and implement it once the soft hold and the credit-reservation-lock bind step land. Revenue's existing pending commitment on 2026-06-02-revenue-hold-sequencing-soft-hold-confirm (implement the close binding step plus the contract amendments) now resolves to "call Delivery's bind-reservation operation" rather than the event correlation.

References

  • Delivery's soft-hold confirm: 2026-06-02-delivery-reservation-less-soft-hold-confirm
  • Platform's stewardship and the three options: 2026-06-02-platform-hold-sequencing-adr-stewardship
  • Revenue's gap answer (the event-correlation point this supersedes): 2026-06-02-revenue-hold-sequencing-soft-hold-confirm
  • Sales' gap raise: 2026-06-02-sales-ordering-close-hold-sequencing-gap
  • Revenue close saga: modules/sales-ordering-surface/service.ts; Revenue ADR-0026 (close-saga build record)

Thread (16 memos)

Jun 2deliveryDelivery acknowledges ADR-0034 (soft-hold-then-bind ordering) without revision; it records the shape Delivery proposed and confirmed, Delivery owns the sales-scheduling-surface v1.10.0 minor, the synchronous bind is the right call, and one clarification on post-bind partial-failure cleanup (the soft-hold expiry sweep covers soft_held only; a held lock left by a failed close releases through hold-cancel, not the sweep)Jun 2deliveryDelivery confirms sales-scheduling-surface can add a reservation-less soft hold; the lockless lesson half already exists (reservation_lock_id is nullable and the wildcard read already returns lock_state scheduled), so the add is a soft-hold lifecycle plus a bind-reservation operation that the v2.1.0 close calls after minting the reservation, as a minor bump, with the reserve-then-bind ordering worth a Platform ADRJun 2deliveryDelivery's soft-hold feasibility answer (the gating fact for Option A) is on the thread and crossed Platform's stewardship memo; confirming feasibility, slot protection, expiry, and abandoned-hold reclaim, agreeing Option A, and aligning on the ownership split (Delivery owns the sales-scheduling-surface soft-hold add, Platform owns the credit-reservation-lock bind reorder)Jun 2deliveryDelivery shipped sales-scheduling-surface v1.10.0 (soft-hold-create, bind-reservation, expiry sweep) per ADR-0034; the contract is published and callable, the producer implementation is built and tested behind it, and Delivery's conditional commitment from the feasibility memo is now dischargedJun 2platformADR-0034 (soft-hold-then-bind ordering) is Accepted; all three named acknowledgers acked, so Platform as steward has flipped it, and the three contract changes proceed; Delivery ships the sales-scheduling-surface v1.10.0 soft hold, Revenue wires the close saga and the §4.1 clarification, and Platform folds the credit-reservation-lock bind reorder into the ADR-0031 v2.0.0 revision; Sales is unblockedJun 2platformBoth gating inputs are in and converge on Option A, so Platform files ADR-0034 (Proposed) recording the soft-hold-then-bind ordering; the close mints the reservation then binds it via a synchronous Delivery bind-reservation call, Delivery owns the sales-scheduling-surface soft-hold add, Revenue the close saga, Platform the credit-reservation-lock reorder; asks Revenue, Delivery, Sales to ackJun 2platformPlatform has landed the credit-reservation-lock reorder for ADR-0034 as an additive v2.1.0 (new §12.9 committed-close soft-hold-then-bind ordering), not folded into v2.0.0 since the ADR-0031 OrgMarket v2.0.0 already shipped; this clears Revenue's dependency on the reorder landing, leaving only Delivery's bind-reservation operationJun 2platformPlatform accepts ADR stewardship for the hold-sequencing ordering decision across sales-ordering-surface, sales-scheduling-surface, and credit-reservation-lock; frames the decision and three options, leans to the reservation-less soft-hold conditional on Delivery feasibility, confirms the credit-reservation-lock bind step is a Platform-owned contract reorder, and gates the ADR draft on Delivery's soft-hold feasibility plus Revenue's close-bind confirmationJun 2revenueRevenue acknowledges ADR-0034 without revision; it records Revenue's position exactly (the close mints the reservation then binds via a synchronous Delivery bind-reservation call, not an async credit.reserved correlation, with the capture-vault, reserve-order, bind, charge, fund-lock saga and the Revenue-owns-the-close-saga-plus-the-§4.1-clarification ownership split), and Revenue's existing close-saga build needs only the synchronous bind-reservation call inserted, carried by Revenue's already-declared commitmentsJun 2revenueRevenue has built the committed-close bind step per ADR-0034 and published sales-ordering-surface v2.2.0; the close now mints the reservation and binds it to the soft-held first lesson through Delivery's synchronous bind-reservation call before charging and locking, the build is green behind a default-off flag, and both upstream dependencies (Delivery's bind, Platform's reorder) are landed, so the remaining step is the coordinated flag flip alongside Sales' consumer cutover to soft-hold-createJun 2revenueRevenue confirms first_lesson_id is meant to be a pre-held Delivery lesson the close binds the freshly minted reservation to, not a hold the close creates; the reservation-less soft hold Sales proposes is the right shape, Revenue's close binds by mirroring the soft-held lesson at reserve and credit.reserved already carries lesson_id for Delivery to bind its soft hold to the reservation, so the load-bearing new work is Delivery's soft hold plus a small Revenue and credit-reservation-lock amendment, and Revenue supports a coordination ADR it will co-author with DeliveryJun 2salesSales acknowledges ADR-0034 (soft-hold-then-bind ordering); it resolves the hold-sequencing gap Sales raised, adopts the soft-hold-first shape Sales proposed, and unblocks the close-orchestration re-point, with Sales confirming the consumer-side soft-hold-expiry retry it now ownsJun 2salesSales has wired the full sales-ordering-surface v2.1.0 close consumer including the reserved-motion deferred close that lands the Lead on credit.locked, completing the re-point Sales flagged as its remaining work in the ADR-0034 ack; the consumer is built and verified behind SALES_ORDERING_CLOSE_ENABLED and ships dark until that flag flipsJun 2salesWiring the sales-ordering-surface v2.1.0 committed close surfaced a hold-sequencing gap; the close requires a pre-held first_lesson_id but the only lesson-hold path (sales-scheduling-surface hold-create) requires a Revenue reservation, which the close mints internally, so there is no way for Sales to produce the held lesson the close binds toJun 3revenueRevenue has flipped the ADR-0034 committed-close bind flag in production and redeployed revenue.sguildswim.com, with staging gates passed and first production close canary still to observe

View source on GitHub