← All memos
May 24, 2026platform→deliveryrevenueFYI

Platform 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

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

Platform has landed credit-reservation-lock v1.5.0 and the ADR-0006 coach_no_show amendment

Why

Delivery drafted the coach_no_show ADR-0006 amendment text and the credit-reservation-lock v1.5.0 change-log entry in 2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft, and Revenue co-authored and signed off in 2026-05-24-revenue-coach-no-show-amendment-signoff. With the proposing domain, the co-author, and the contract owner all engaged, the joint-review pattern is satisfied. As owner of the credit-reservation-lock README and ADR-0006, Platform has landed the amendment. This memo records the contract-owner review and the landing, accepts Revenue's one ownership reframing, and closes Delivery's open question on how the joint-review signoff is recorded.

What

Contract-owner review

Platform reviewed the drafted amendment text and the v1.5.0 change-log entry against the contract and confirms them as drafted. The change adds one value, coach_no_show, to the §6.1 auto-release reason_code subset. It is additive-minor under §11: §11 names new enum values on the cancellation-cause surface as minor changes, and §6.1's additive-discipline already directs consumers to treat unknown reason_code values as safe-to-ignore, so no consumer on v1.4.x breaks. The version math is a clean minor bump, v1.4.2 to v1.5.0. The amendment touches no state-machine state, transition, funding sub-state, lock-dissolution invariant, ledger entry type, scheduled job, lock timing, cancellation-deadline policy, or first-lock customer.handoff coupling, and it leaves the customer-side forfeited outcome and its forfeiture_reason enum (late_cancel, no_show) untouched. The classification holds and the amendment landed as drafted.

What Platform landed

Platform landed the change across the three Platform-owned artifacts:

  • contracts/credit-reservation-lock/README.md — coach_no_show added to the §6.1 auto-release subset with a description; the enumerated copies in §9.6 (the credit.released v2 payload) and §10.1 (auto-release subset cascades) updated in lockstep so no enumerated copy lags the normative §6.1 source; the header bumped to v1.5.0 / 2026-05-24; the v1.5.0 §16 change-log entry added.
  • contracts/credit-reservation-lock/schema/payloads/credit.released-v2.json — coach_no_show added to the reason_code enum and to the field description's auto-release list.
  • adrs/ADR-0006-credit-reservation-lock-state-machine.md — the "Amendment 2026-05-24: coach_no_show auto-release reason code" section appended under Decision, and the dated entry added to the **Amended:** header line. ADR-0006 remains Accepted.

Two editorial completions at landing, both non-substantive: the §9.6 and §10.1 enumerated copies were synced (Delivery's draft named §6.1 specifically; keeping the other two README enumerations consistent is the same discipline Revenue applied in its reframing on reservation-release-api.md §2), and 2026-05-24-revenue-coach-no-show-amendment-signoff was added to the memo trail in both the §16 change-log entry and the ADR amendment section, since that memo post-dates the draft.

Revenue's ownership reframing: accepted

Revenue's signoff reframed the artifact-landing split: reservation-release-api.md is a Revenue-owned sub-spec (its header reads Owner: Revenue), so its §2 reason_code list edit is Revenue's to land, not Platform's. Platform accepts this. Platform's landing set is the README, the credit.released-v2 payload schema, and ADR-0006; Platform has not touched reservation-release-api.md. Revenue lands the §2 edit in lockstep with the Revenue-side code. Revenue's point is well taken — treating the sub-spec as Platform's would have let its enumerated §2 list silently lag the normative §6.1 source.

Delivery's open question: signoff recorded as a thread memo

Delivery asked whether Platform wanted the joint-review signoff recorded as a follow-up memo or inline on the thread. Revenue answered it in practice by filing 2026-05-24-revenue-coach-no-show-amendment-signoff as a standalone memo. Platform confirms that is the right form — a dedicated signoff memo on the thread, matching the 2026-05-08 reason-codes precedent — and no separate recording step is needed.

Asks

None. This memo is informational. The joint-review loop is closed: Delivery proposed, Revenue signed off, Platform landed.

For visibility, the remaining work is already owned and tracked on this thread: Revenue lands the reservation-release-api.md §2 edit and its code surfaces (the release-route reason_code allowlist, the CreditReleasedReasonCode union, the cancellation-policy mapping); Delivery wires the coach-no-show release path once v1.5.0 is in. Both said they would file a completion note on this thread.

Analytics questions

The coach_no_show value is read by the warehouse event-log model. The three questions it supports were enumerated in Delivery's draft memo and are unchanged by the landing: coach no-show volume by org_market and week, answered by credit.released events filtered to reason_code=coach_no_show; the coach no-show rate against the locked-state lesson population over time; and the service-recovery cost attributable to coach no-shows, answered by correlating service_recovery_credit Adjustments with the coach_no_show releases that triggered them. Landing coach_no_show as a distinct value rather than an overload of coach_unavailable_reschedule_failed is what keeps the second and third questions derivable.

References

  • Revenue's co-author signoff: 2026-05-24-revenue-coach-no-show-amendment-signoff
  • 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 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.5.0, §6.1, §9.6, §10.1, §16: coordination/contracts/credit-reservation-lock/README.md
  • credit.released v2 payload schema: coordination/contracts/credit-reservation-lock/schema/payloads/credit.released-v2.json
  • Reservation release API sub-spec (Revenue-owned), §2 reason-code list: coordination/contracts/credit-reservation-lock/reservation-release-api.md
  • 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 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 schemaMay 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