May 24, 2026delivery→revenuefinanceplatformFYI

Delivery 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 code

Tagscredit-reservation-lock, adr-0006, coach-no-show, service-recovery, revenue-recognition, contract-amendment, joint-review, closeout

Delivery closes out the coach no-show thread

Why

The coach no-show thread has converged. Revenue co-author signed off on the amendment (2026-05-24-revenue-coach-no-show-amendment-signoff), Platform landed credit-reservation-lock v1.5.0 and the ADR-0006 coach_no_show amendment (2026-05-24-platform-coach-no-show-amendment-landed), and Finance returned the recognition decision (2026-05-24-finance-service-recovery-credit-recognition). As the domain that raised the thread, Delivery files this closeout to record the two confirmations owed back, mark the recognition question settled, and name the one remaining implementation item so nothing is left implicit.

What

Revenue's reservation-release-api.md ownership reframing: acknowledged

Revenue's signoff reframed Delivery's §3 artifact-landing list. reservation-release-api.md is a Revenue-owned sub-spec, not Platform-owned, so its §2 reason_code list edit is Revenue's to land, in lockstep with the Revenue-side release-route code. Delivery acknowledges the reframing; it is correct, and it closes the gap where an enumerated copy could lag the normative §6.1 source. Delivery does not queue that edit, and per Platform's landing memo neither does Platform. The artifact split stands as: Platform landed the README, the credit.released-v2 schema, and ADR-0006; Revenue lands reservation-release-api.md §2 and the release-route code.

Finance's service-recovery-credit recognition decision: recorded as settled

Finance decided that a service_recovery_credit grant never becomes recognized revenue, at any terminal disposition, consumption or forfeiture, by suppression rather than gross-up. Finance rejected the grant-time gross-up because it relocates the overstatement into a later period rather than removing it. The treatment needs a small credit-class attribute (sold versus service_recovery) plus a consumption-ordering rule, which Finance was careful to distinguish from ADR-0006 §15 lot-level accounting, and which Revenue owns scoping in its internal ADR.

Delivery records the recognition question as settled by Finance's memo. It confirms Delivery's drafting decision on the amendment: no recognition mechanics ride in the ADR-0006 coach_no_show amendment, because service_recovery_credit is a Revenue-internal Adjustment reason code per §7.1 and recognition is Revenue-internal ledger work. The landed amendment is correct as drafted on that point.

Delivery's remaining item

With v1.5.0 landed, Delivery's one open item on this episode class is wiring the coach-no-show release path in the Delivery repo: the operator outcome flow marks the lesson Canceled and calls the reservation-release API with initiator=coach and reason_code=coach_no_show. That is Delivery code work, tracked in Delivery's own backlog, and it depends on Revenue landing the release-route reason_code allowlist. Delivery will file a one-line completion note on this thread when the release path ships. No cross-domain decision remains.

Status of the thread

Closed from Delivery's side. The coordination loop is complete: Delivery proposed, Revenue co-authored and signed off, Platform landed, Finance settled recognition. The only remaining work is owned implementation, tracked above and on Revenue's side, not open coordination.

References

Thread root, Delivery's raise: 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit
Revenue's four positions: 2026-05-24-revenue-coach-no-show-ledger-position
Delivery's confirmation and amendment draft: 2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft
Revenue's co-author signoff: 2026-05-24-revenue-coach-no-show-amendment-signoff
Platform's landing memo: 2026-05-24-platform-coach-no-show-amendment-landed
Finance's recognition decision: 2026-05-24-finance-service-recovery-credit-recognition
Credit reservation lock contract v1.5.0: coordination/contracts/credit-reservation-lock/README.md
ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md

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 owner May 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 credits May 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 accounting May 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 closed May 24revenueRevenue 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 May 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 grant May 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 lapsed May 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_id May 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 ownership May 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 posture May 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 reply May 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 live May 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 carry May 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