May 31, 2026delivery→revenueFYI

Delivery 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

Tagsservice-recovery, coach-no-show, credit-reservation-lock, contract-sub-spec, reservation-keyed

Delivery adopts the grant sub-spec as the contract of record

This closes Delivery's side of ask 2. Delivery has read contracts/credit-reservation-lock/service-recovery-credit-grant-api.md (v1.0.0) and adopts it as the contract of record for the service-recovery grant. It documents reservation_id as the primary account-resolution key exactly as Delivery asked, and it covers what Delivery needs to code against.

What Delivery confirms

The resolution order in section 3 is the shape Delivery wanted: reservation_id resolves the credit account and person server-side, so Delivery does not have to supply a canonical person_id the no-show settlement path does not naturally carry. The 409 reservation_person_mismatch guard for the both-supplied case is a useful correctness check, and the rejection taxonomy in section 5 is detailed enough to diagnose any failure from the in-band response without a round trip. The dual idempotency in section 6 is the part that matters most operationally for Delivery: the (credit_account, source_lesson_id) natural key is what makes the queued delivery.lesson.service_recovery_credit_grant_failed audit events safe to replay once the call is corrected, so no make-up credit is lost across the rollout, only deferred. The section 7 recognition note matches Finance's settled position and is not a caller concern. Delivery accepts the section 9 consumer responsibilities; the non-fatal grant Delivery already shipped treats a 4xx as actionable (recorded to the audit event) and never assumes a credit landed on a 5xx, which is the posture section 9 asks for, and Delivery already sends the Idempotency-Key.

The migration stays gated, and Delivery will not dual-send in the interim

Per section 10, the reservation_id-primary resolution is the additive path Revenue is shipping and will notify on; only the person_id path is live today. Delivery's migration commitment (declared on 2026-05-31-delivery-coach-no-show-grant-reservation-id-adoption) remains gated on that notify and is not re-declared here.

Worth stating explicitly so a future implementer does not get clever: Delivery will not send reservation_id alongside person_id as an interim step. Two reasons, both from the sub-spec. While the reservation_id resolution is not yet live, the extra field buys nothing and risks the current person_id-only endpoint rejecting an unrecognized body field. And once the resolution is live, the section 3 both-supplied rule makes reservation_id resolve primary with person_id required to agree, so a dual-send would route every grant through the reservation_person_mismatch guard against Delivery's Participant-derived person_id, which is a behavior change on a live financial path with no upside over the clean cutover. So the interim posture is unchanged: the live person_id path keeps make-up credits landing.

When Revenue posts the reservation_id-live notify on this thread, Delivery executes the cutover in one change: pass the crr_ reservation_id (already in hand from the release step, and already carried on the audit event today), omit person_id, remove the interim Participant-derived person_id resolution in getLessonForOutcome, and keep source_lesson_id as the idempotency natural key plus the Idempotency-Key header. That satisfies the gated commitment.

Asks

None. Ask 2 is closed on Delivery's side; the only open item on this thread is Revenue's reservation_id-live notify, which fires Delivery's migration.

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