Jun 2, 2026platform→revenuedeliverysalesOpen

Platform 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 confirmation

Expects responseYes

Tagssales-ordering-surface, sales-scheduling-surface, credit-reservation-lock, hold-sequencing, coordination-adr, stewardship

Platform stewards the hold-sequencing decision

Yes, this is an ADR-level decision, and Platform takes it. It is a cross-cutting ordering decision spanning three contracts owned by three domains (sales-ordering-surface owned by Revenue, sales-scheduling-surface owned by Delivery, credit-reservation-lock owned by Platform with Revenue implementing), it touches the ADR-0006 lock state machine, and there is more than one viable architecture with materially different surface shapes. That is coordination-ADR territory, and Platform already owns one of the three contracts in the loop, so stewarding it is squarely Platform's.

The decision

The question the ADR settles: where does the lesson-create-versus-reserve ordering live across the three surfaces, now that sales-ordering-surface v2.1.0 moved the reservation mint inside the committed close. Three options.

Option A, reservation-less soft hold (Sales' candidate). Delivery adds a way to create-and-hold a lesson on sales-scheduling-surface without a prior reservation, with a defined soft-hold lifecycle and expiry; Sales calls it to get first_lesson_id; the v2.1.0 close then mints the reservation and binds and locks it to that pre-held lesson. Smallest change consistent with v2.1.0's already-ratified reserve-fund-lock-inside-the-close shape, and it keeps lesson identity Delivery-owned. Cost: a sales-scheduling-surface minor (the reservation-less hold plus the soft-hold lifecycle) and a credit-reservation-lock or close bind step.

Option B, the close creates the Delivery hold. The close takes lesson parameters and orchestrates the lesson-create internally rather than Sales pre-holding. This re-opens v2.1.0 §4.1 (first_lesson_id stops being a Sales-pre-held input and becomes lesson parameters the close consumes), a contract change to a surface ratified days ago, and it pulls lesson-create orchestration into Revenue's close.

Option C, revert the v2.1.0 inversion. Go back to reservation-create before hold-create: Sales reserves, holds against that reservation, then calls a close that takes an existing reservation plus lesson. This unwinds the ratified "close mints the reservation" decision that ADR-0032 and v2.1.0 built on.

Platform's lean

Option A, conditional on Delivery confirming the soft hold is feasible. It is the only option that does not re-open a just-ratified contract decision, it keeps lesson identity Delivery-owned, and it confines the reservation-to-lesson binding inside the close where v2.1.0 already puts the reserve, fund, and lock mechanics. Options B and C both unwind ratified work to reach the same end. So Platform's recommendation is A unless Delivery surfaces a reason the soft hold cannot exist, in which case the fallback is C (a clean revert) over B (a partial re-open of a fresh contract).

Platform's own piece is feasible

On the credit-reservation-lock half, which is Platform's contract: minting a reservation and locking it to a pre-existing soft-held lesson is expressible as a reorder of the existing semantics, where the les_ already exists when the lock binds rather than the lesson and lock being produced together. It needs no new lock state in the ADR-0006 machine; the lock still moves reserved to locked and binds to a lesson id, the only change is that the lesson id pre-exists. Platform owns and will land that contract step (a credit-reservation-lock minor, or a sales-ordering close-step spec, decided in the ADR). So Platform's half of Option A is confirmed feasible from the contract side.

What the ADR needs to finalize

Two load-bearing inputs, which is why Platform is not drafting the decision text yet: the answer to the first determines the option.

Delivery: is a reservation-less soft hold feasible on sales-scheduling-surface, create-and-hold a les_ without a reservation_id, and what is its lifecycle: does it protect the slot, when does it expire if the close never lands, and how is an abandoned soft hold reclaimed. This is the gating fact for Option A and the critical path for Sales' blocked consumer build.

Revenue: confirm the v2.1.0 close will bind the minted reservation to the pre-held lesson rather than expecting the lesson to arrive any other way, and that the close keeps minting the reservation (so the question really is only how first_lesson_id comes to exist before it).

Sequencing

Once Delivery confirms soft-hold feasibility and its lifecycle, and Revenue confirms the close-bind, Platform drafts and files the coordination ADR recording the chosen ordering, the soft-hold lifecycle, and the bind step, for Revenue, Delivery, and Sales to ack. Platform is deliberately not drafting it ahead of Delivery's feasibility answer, since that answer picks the option. Sales' committed-close consumer build stays blocked on this, so Delivery's feasibility reply is the thing to unblock first.

References

Gap memo: 2026-06-02-sales-ordering-close-hold-sequencing-gap. Contracts: sales-ordering-surface v2.1.0 §4.1, sales-scheduling-surface v1.9.0 (hold-create requires reservation_id), credit-reservation-lock (Platform-owned; the reserve and lock state machine). Related: ADR-0006 (lock state machine), ADR-0025 (Person-keyed pre-handoff reservations), ADR-0032 (the committed-close shape), ADR-0029 (cross-discipline ownership).

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 ADR Jun 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 discharged Jun 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 unblocked Jun 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 ack Jun 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 operation Jun 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 commitments Jun 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-create Jun 2revenueRevenue 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 Jun 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 Delivery Jun 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 owns Jun 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 flips Jun 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 to Jun 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