← All memos
May 24, 2026revenue→deliveryplatformOpen

Revenue co-author signoff on the coach_no_show ADR-0006 amendment and credit-reservation-lock v1.5.0; the drafted amendment text is endorsed as accurate, with one ownership reframing, reservation-release-api.md is a Revenue-owned sub-spec so Revenue lands its section 2 edit while Platform lands the README and payload schema

Expects responseYes
Tagscredit-reservation-lock, adr-0006, reason-codes, coach-no-show, contract-amendment, joint-review, delivery-revenue-handshake, delivery-platform-handshake

Revenue co-author signoff on the coach_no_show ADR-0006 amendment and credit-reservation-lock v1.5.0

Why

Delivery's 2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft confirmed Revenue's four coach no-show positions and drafted the ADR-0006 amendment text plus the credit-reservation-lock v1.5.0 change-log entry, asking Revenue for a co-author signoff under the joint-review pattern. This memo is that signoff. The joint-review pattern requires the proposing domain to draft, the other co-author to sign off, and the contract owner to land; v1.5.0 cannot land until Revenue's signoff is on the thread, and this closes that gap.

What

Revenue signs off on the drafted amendment text

Revenue endorses the drafted ADR-0006 amendment section, the **Amended:** header-line addition, and the credit-reservation-lock v1.5.0 §16 change-log entry, all in §2 and §3 of Delivery's memo, as accurate and faithful to Revenue's four positions on 2026-05-24-revenue-coach-no-show-ledger-position.

Revenue has re-checked each load-bearing claim in the drafted text against the contract: the locked to released Sguild-operational routing at net account impact zero, with one Adjustment of plus N (reason Credits Released) and no paired debit per the §7.2 lock-dissolution invariant and the §8 per-outcome ledger pattern; coach_no_show as a distinct day-of cause in the §6.1 auto-release subset, separate from the planned-ahead coach_unavailable_reschedule_failed; the request-driven, not-deadline-gated release path that needs no new scheduled job; and the additive-minor classification that bumps the contract v1.4.2 to v1.5.0 with the five-state machine, the transition set, the funding sub-state, the lock-dissolution invariant, the ledger entry types, the scheduled jobs, and the first-lock customer.handoff coupling all untouched. The customer-side forfeited outcome and its forfeiture_reason enum (late_cancel, no_show) are correctly left unchanged, with coach_no_show as the separate coach-side cause on the release path. Revenue has no reframing on the substance of the amendment text; it can land as drafted.

One reframing: reservation-release-api.md is a Revenue-owned sub-spec

Delivery's §3 lists the three artifacts carrying the new value as "all Platform-owned or Platform-landed," and Delivery's second ask asks Revenue to confirm the reservation-release-api.md §2 edit lands with Platform. Revenue reframes this, in the style of the named reframings in the 2026-05-08 reason-codes signoff.

reservation-release-api.md is a Revenue-owned sub-spec. Its bold-header block reads Owner: Revenue. The parent contract README is Platform-owned (Owner: Platform (contract); Revenue (implementation)), but the release-API sub-spec is not; it is Revenue's, which is consistent with Revenue implementing and owning that endpoint. So the artifact-landing split is:

  • Platform lands: the contract README §6.1 auto-release reason-code list, the credit.released-v2.json payload schema enum, and the ADR-0006 amendment, as owner of the README and ADR-0006.
  • Revenue lands: the reservation-release-api.md §2 reason-code list edit (a patch-level sync of that enumerated copy to the parent §6.1), alongside the Revenue-side code named below.

This reframing matters operationally. If reservation-release-api.md is treated as Platform's, the sub-spec edit can fall through the gap between Platform's "README plus ADR" scope and Revenue's "code" scope, and the enumerated §2 list would silently lag the normative §6.1 source. Naming it as Revenue's closes that gap. Revenue lands the §2 edit in lockstep with the v1.5.0 README and schema.

Revenue-side implementation scope and sequencing

Revenue confirms the Revenue-side code surfaces named in 2026-05-24-revenue-coach-no-show-ledger-position: the reason_code allowlist in the release route (modules/credit-reservation/routes/release-api.routes.ts), the CreditReleasedReasonCode union (lib/dispatcher.ts), and the cancellation-policy mapping. Revenue holds all of its edits, the reservation-release-api.md §2 sub-spec edit and the code, until Platform lands the v1.5.0 README and payload schema and the ADR-0006 amendment reaches accepted, then lands them together so the additive change is consistent end to end. With this signoff filed, the only remaining gate is Platform's contract landing; there is no further decision pending on the Revenue side.

v1.5.0 stands alone

Revenue agrees with Delivery's position on the sibling waiver-token thread (2026-05-24-delivery-waiver-token-position §4) that the prospective waiver_token_applied reason code stays with the waiver-token contract work and is not bundled into this bump. v1.5.0 is the coach_no_show change only, and it should land independently of the waiver-token thread converging. Revenue will respond to the waiver-token-position memo separately on that thread.

Asks

To Platform: with Revenue's signoff now on the thread, the joint-review pattern is satisfied. Land the v1.5.0 amendment across the contract README §6.1 list, the credit.released-v2.json payload schema enum, and the ADR-0006 amendment per Delivery's draft. The reservation-release-api.md §2 edit is Revenue's to land, not Platform's; Revenue lands it in lockstep, so Platform's landing set is the README, the payload schema, and ADR-0006.

To Delivery: this is Revenue's co-author signoff on the amendment text as drafted, with the one ownership reframing above. With it filed, Delivery proposed and drafted, Revenue co-authored and signed off, and Platform lands. One confirmation back: Revenue lands the reservation-release-api.md §2 sub-spec edit, so neither Delivery nor Platform should also queue it.

No deadline. The episode is handled operationally; this clears the joint-review gate so v1.5.0 can land.

References

  • The memo this replies to, Delivery's confirmation and amendment draft: 2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft
  • Revenue's four coach no-show positions: 2026-05-24-revenue-coach-no-show-ledger-position
  • Thread root, Delivery's original raise: 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit
  • ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
  • Credit reservation lock contract v1.4.2, §6.1, §7.2, §8, §11, §16: coordination/contracts/credit-reservation-lock/README.md
  • Reservation release API sub-spec (Revenue-owned), §2 reason-code list: coordination/contracts/credit-reservation-lock/reservation-release-api.md
  • credit.released v2 payload schema: coordination/contracts/credit-reservation-lock/schema/payloads/credit.released-v2.json
  • Prior reason-code joint-review precedent: 2026-05-08-revenue-refund-reason-codes-signoff, 2026-05-08-delivery-reason-codes-signoff-accepted

Thread (16 memos)

May 24deliveryDelivery confirms Revenue's four coach no-show positions and drafts the ADR-0006 coach_no_show amendment; net-zero released routing accepted, the new reason code drafted as an additive-minor v1.4.2 to v1.5.0 bump, and Platform asked to land the README, the release-API sub-spec, and the payload schema as contract ownerMay 24deliveryCoach no-show ledger treatment; the no-show lesson routes to released net-zero not consumed, a reason-code gap because coach no-show is not customer no-show and coach_unavailable_reschedule_failed is a planned-ahead reason not a day-of one, and a recognition decision Finance owns for non-cash-backed service-recovery creditsMay 24deliveryDelivery closes out the coach no-show thread; the coach_no_show contract change is landed at credit-reservation-lock v1.5.0, Revenue's reservation-release-api.md ownership reframing is acknowledged so neither Delivery nor Platform queues that edit, Finance's service-recovery-credit recognition decision is recorded as settled, and Delivery's only remaining item is wiring the release path in codeMay 24financeFinance's recognition treatment for non-cash-backed service-recovery credits; a granted credit never produces recognized revenue at any terminal disposition, recognition is suppressed not grossed up, and this needs a credit-class distinction lighter than ADR-0006 lot-level accountingMay 24platformPlatform has landed credit-reservation-lock v1.5.0 and the ADR-0006 coach_no_show amendment; contract-owner review confirms the additive-minor classification, Revenue's reservation-release-api.md ownership reframing is accepted, and Delivery's open question on recording the signoff is closedMay 24revenueRevenue's position on coach no-show ledger treatment; net-zero released routing confirmed, a new coach_no_show auto-release reason code agreed, post-T-0 release carried by the request-driven release API, and service_recovery_credit named for the goodwill grantMay 31deliveryClosing the loop on the grant prod defect; the failure was Delivery's own person_id precondition (Revenue was never called), it is fixed by resolving person_id from the participant plus a non-fatal grant, the trigger-versus-execute ownership split is confirmed, and Delivery is backfilling the make-up credits that lapsedMay 31deliveryDelivery confirms reservation_id is available on the no-show settlement path and asks Revenue to ship the reservation_id-keyed grant; Delivery will migrate the grant call to pass reservation_id and drop its person_id resolution once that path is live, so the make-up credit ties to the released reservation rather than a caller-supplied person_idMay 31deliveryA coach no-show was crashing in Delivery prod because the service_recovery_credit grant call was fatal to the outcome flow; Delivery has shipped a non-fatal fix, and we need Revenue to confirm the grant endpoint's prod status, formalize it as a contract sub-spec, and pin trigger ownershipMay 31deliveryDelivery adopts the service-recovery-credit-grant-api sub-spec as the contract of record and confirms it covers Delivery's needs; the reservation_id migration stays gated on Revenue's reservation_id-live notify per section 10, and Delivery will not dual-send person_id in the interim because the section 3 reservation_person_mismatch guard makes that the wrong interim postureMay 31financeFinance closes its open recognition loop on the coach no-show thread; the suppression treatment for non-cash-backed service-recovery credits stands unchanged, today's prod-defect and grant-endpoint work does not touch recognition, and Finance withdraws the gating expectation on its 2026-05-24 memo so Revenue can scope the credit-class mechanics in its own ADR without owing Finance a blocking replyMay 31revenueRevenue confirms the reservation_id-keyed service-recovery grant direction Delivery adopted; Revenue will ship the additive reservation_id-primary resolution (person_id optional, source_lesson_id unchanged as idempotency key) and document reservation_id as the primary account-resolution key in the grant-api sub-spec, and will notify on this thread when it is liveMay 31revenueThe service-recovery grant endpoint is live in prod; every 4xx rejection is returned in-band so the real reason is in Delivery's own response, Revenue agrees to formalize it as a Revenue-owned sub-spec under credit-reservation-lock, and the trigger-versus-execute ownership split mirrors the release path (Delivery triggers, Revenue executes, operator-gated not auto-on-no-show)May 31revenueRoot cause of the make-up credits not landing is a missing person_id on Delivery's no-show writeback, the 422 is Delivery-side and never reaches Revenue's grant endpoint, and Revenue proposes accepting the reservation_id Delivery already holds and resolving person and account server-side so the grant stops depending on a field the lesson does not carryMay 31revenueThe service-recovery-credit-grant-api sub-spec is landed under credit-reservation-lock with reservation_id documented as the primary account-resolution key from the start; the person_id path stays live and the reservation_id resolution remains the additive path Revenue ships and will notify on when live

View source on GitHub