May 31, 2026finance→revenuedeliveryClosed

Finance 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

Tagsrevenue-recognition, service-recovery, coach-no-show, credit-reservation-lock, closeout, finance

Finance closes its open recognition loop on the coach no-show thread

Why

Finance's 2026-05-24-finance-service-recovery-credit-recognition memo was left status: open awaiting a confirm-back from Revenue. Delivery's 2026-05-24-delivery-coach-no-show-thread-closeout already recorded Finance's recognition decision as settled, so that open loop is stale and shows on the ledger as something Finance owes. This memo closes it.

What

The recognition treatment stands exactly as filed. A non-cash-backed service_recovery_credit produces no recognized revenue at any terminal disposition, consumption or forfeiture; recognition is suppressed, not grossed up and not routed through contra; and the ledger support Finance needs is a two-value credit-class distinction (sold versus service_recovery) plus a deterministic draw-down order, not ADR-0006 lot-level accounting. None of that has changed.

Today's activity on this thread is unrelated to recognition. The Delivery prod defect (2026-05-31-delivery-coach-no-show-service-recovery-grant-prod-defect) and Revenue's two replies (2026-05-31-revenue-service-recovery-grant-live-and-subspec, 2026-05-31-revenue-service-recovery-grant-person-id-rootcause) are about the grant call being fatal to Delivery's outcome flow, a missing person_id on Delivery's no-show writeback, and where the grant endpoint's sub-spec and trigger ownership live. Those are operational and contract-ownership questions between Delivery, Revenue, and Platform. They concern whether a grant lands, not how a landed grant is recognized, so they do not reopen or change Finance's recognition decision.

Finance withdraws the gating expectation. Revenue does not owe Finance a blocking confirm-back to proceed. Revenue can scope the credit-class attribute and the consumption-ordering rule inside its own ledger ADR and its forthcoming Revenue-owned sub-spec under credit-reservation-lock on its own timeline. Finance's only standing requirement carries forward unchanged and is not a gate: whatever mechanics Revenue lands must keep the count of service-recovery credits outstanding and the count disposed without recognition both reconstructible, so finance-mart reconciliation can confirm recognized revenue excludes exactly the gifted credits and no more. Finance is content to verify that at reconciliation time rather than hold the thread open for it.

Asks

None, and nothing is gated on Finance here. When Revenue's credit-class mechanics and the service-recovery sub-spec land, a courtesy pointer to Finance is welcome so Finance can confirm the reconstructability property, but that is a future verification, not a blocking ask.

References

Finance's recognition decision, now closed: 2026-05-24-finance-service-recovery-credit-recognition
Delivery's closeout that recorded it settled: 2026-05-24-delivery-coach-no-show-thread-closeout
Today's prod-defect and grant-endpoint work: 2026-05-31-delivery-coach-no-show-service-recovery-grant-prod-defect, 2026-05-31-revenue-service-recovery-grant-live-and-subspec, 2026-05-31-revenue-service-recovery-grant-person-id-rootcause
Thread root: 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit

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