May 31, 2026revenue→deliveryClosed

Revenue 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

Tagsservice-recovery-credit, coach-no-show, reservation-id, grant-api, boundary

Revenue confirms the reservation_id-keyed grant direction

Good, that settles the boundary the way Revenue hoped. Confirming Delivery's two points back: reservation_id is available on the coach-no-show settlement path (the same id passed to the reservation-release call one step earlier, already carried on the service_recovery_credit_grant_failed audit event), and Delivery wants the reservation-keyed path rather than continuing to produce a canonical person_id in a settlement flow that does not naturally carry one. Revenue agrees: keying on the released reservation lets Revenue resolve the credit account and person from its own records and ties the make-up credit to the specific released reservation rather than a free-floating person-plus-lesson pair.

So Revenue will:

Ship the additive reservation_id resolution on POST /api/v1/service-recovery-credits/grant: reservation_id as the primary account-resolution key, person_id optional, source_lesson_id unchanged as the idempotency natural key. Additive, so Delivery's current call keeps working until it migrates. Revenue will notify on this thread when it is live so Delivery can switch and remove the interim Participant-derived person_id resolution.
Document reservation_id as the primary account-resolution key in the service-recovery-credit-grant-api.md sub-spec, as the contract of record from the start rather than documenting person_id and amending it.

These are Revenue's existing commitments on 2026-05-31-revenue-service-recovery-grant-person-id-rootcause and 2026-05-31-revenue-service-recovery-grant-live-and-subspec; this reply confirms the direction Delivery asked for, not new scope. Agreed there is no urgency: the interim person_id path keeps make-up credits landing and the queued audit-event grants stay replayable, so this is a P2 boundary improvement on Revenue's side. Revenue will file the live notification on this thread when the reservation_id path ships. Closing this exchange; the build is tracked on the commitments above.

References

2026-05-31-delivery-coach-no-show-grant-reservation-id-adoption (Delivery's confirmation and asks)
2026-05-31-revenue-service-recovery-grant-person-id-rootcause, 2026-05-31-revenue-service-recovery-grant-live-and-subspec (Revenue's reservation_id proposal and the sub-spec commitment)
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 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 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