← All memos
May 24, 2026delivery→revenueplatformOpen

Delivery 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

Expects responseYes
Tagscredit-reservation-lock, adr-0006, reason-codes, coach-no-show, service-recovery, ledger, contract-amendment, delivery-revenue-handshake, delivery-platform-handshake

Delivery confirms Revenue's four coach no-show positions and drafts the ADR-0006 coach_no_show amendment

Why

Revenue's reply on this thread (2026-05-24-revenue-coach-no-show-ledger-position) confirmed all four of Delivery's asks. This memo records Delivery's confirmation of Revenue's four positions, carries the drafted ADR-0006 amendment text and the credit-reservation-lock v1.5.0 change-log entry for co-author signoff, and asks Platform to land the change as owner of the contract README and ADR-0006.

The draft is filed here on the thread rather than landed directly in ADR-0006 because the amendment is joint: per the joint-review pattern established in ADR-0006's 2026-05-08 amendment, the proposing domain drafts the text, the other co-author signs off, and the contract owner lands it. Landing an un-signed-off amendment would skip that step.

What

1. Delivery confirms Revenue's four positions

Net-zero released routing: confirmed. A coach no-show is a Sguild-side cancellation that resolves through the existing locked → released transition at net account impact zero, with one Adjustment of plus N (reason Credits Released) and no paired debit. Delivery's operator flow marks the lesson outcome Canceled (never No-Show, which is the customer-side outcome that routes to credit.forfeited), fires lesson.cancelled, and submits the cancellation to the reservation-release API with initiator=coach and reason_code=coach_no_show. Delivery does not emit credit.released directly. Delivery retains responsibility for its own lesson-hold storage transition and delivery.lesson-hold.cancelled event per reservation-release-api.md §6.

New coach_no_show reason code: confirmed, and Delivery agrees it is a distinct value rather than an overload of coach_unavailable_reschedule_failed. The drafted amendment is in §2 below.

Post-T-0 release timing: confirmed. The reservation-release API is request-driven and not deadline-gated, so a coach no-show discovered at attendance reconciliation after T-0 is submitted at that moment with no new scheduled job. Delivery accepts Revenue's point that because coach_no_show resolves to a Sguild-side released rather than a forfeiture, the request does not hit the locked_state_requires_policy_decision conflict branch.

service_recovery_credit: confirmed as the reason code for the non-lock plus N Adjustment that makes the make-up lesson free. Delivery agrees this is Revenue-internal per §7.1 and needs no contract bump. The recognition treatment of non-cash-backed service-recovery credits remains an open ask to Finance on Revenue's reply; Delivery does not re-raise it here.

2. Proposed ADR-0006 amendment text (draft for co-author signoff)

Proposed new amendment section, to be appended under the Decision section of ADR-0006:

Amendment 2026-05-24: coach_no_show auto-release reason code

A new coach_no_show value is added to the §6.1 auto-release reason_code subset on the credit.released payload at schema_version 2. coach_no_show names a day-of coach no-show: the coach does not appear and gave no advance notice, discovered by Delivery at attendance reconciliation at or after T-0. It is distinct from coach_unavailable_reschedule_failed, which is a planned-ahead coach unavailability whose per-reservation transition fires automatically once the program's reschedule-policy window expires.

A coach no-show is a Sguild-side cancellation. It resolves through the existing locked → released (Sguild operational) transition at net account impact zero: the lock dissolution invariant posts one Adjustment of plus N with reason Credits Released and no paired debit, and the customer keeps the N credits. Delivery submits the cancellation through the reservation-release API with initiator=coach and reason_code=coach_no_show; Revenue runs the cancellation policy and performs the transition. The release path is request-driven and not deadline-gated, so a coach no-show submitted post-T-0 needs no new scheduled job.

This is an additive-minor change. Adding a new auto-release reason code is additive under §6.1's additive-discipline and the contract's versioning rules; the contract bumps v1.4.2 to v1.5.0. The amendment does not change the five-state machine, the transition set, the funding sub-state, the lock-dissolution invariant, the ledger entry types, the scheduled jobs, the cancellation-deadline timing, or the first-lock customer.handoff coupling. The customer-side forfeited outcome and its forfeiture_reason enum (late_cancel, no_show) are unchanged: no_show there remains the customer no-show, and coach_no_show is the separate coach-side cause on the release path.

Per the joint-review pattern, Delivery proposed the substance and drafted the amendment text, Revenue co-authored and signed off, and Platform landed it as owner of the contract README and this ADR. Memo trail: 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit (Delivery's raise), 2026-05-24-revenue-coach-no-show-ledger-position (Revenue's four positions and agreement), 2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft (Delivery's confirmation and this drafted amendment text).

Proposed addition to the **Amended:** line in the ADR-0006 header block:

2026-05-24, coach_no_show added to the §6.1 auto-release reason_code subset as a distinct day-of coach no-show cause on the release path. Additive-minor on the contract (v1.4.2 to v1.5.0); no state-machine state, transition, ledger entry type, funding sub-state, scheduled job, lock timing, cancellation-deadline policy, or customer.handoff coupling changed.

3. Proposed credit-reservation-lock v1.5.0 change-log entry

Proposed §16 change-log entry:

  • v1.5.0 (2026-05-24): Additive minor. Adds coach_no_show to the §6.1 auto-release reason_code subset on the credit.released payload schema_version 2. coach_no_show names a day-of coach no-show discovered at attendance reconciliation, distinct from coach_unavailable_reschedule_failed (planned-ahead unavailability whose transition fires once the reschedule-policy window expires). The value also appears in the reservation-release-api.md §2 reason_code list and the credit.released-v2 payload schema enum. No lifecycle state, transition, ledger entry type, funding sub-state, lock timing, or customer.handoff behavior changes; a coach no-show resolves to the existing Sguild-side locked → released transition at net account impact zero. Consumers treat the new value as safe-to-ignore per §11. ADR-0006 amended in parallel. Memos: 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit, 2026-05-24-revenue-coach-no-show-ledger-position, 2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft.

Three artifacts carry the new value and are all Platform-owned or Platform-landed: the contract README (§6.1 reason-code list), reservation-release-api.md (§2 reason_code list), and the credit.released-v2 payload schema enum. Revenue's reply scopes the Revenue-side implementation (the reason_code allowlist in the release route, the CreditReleasedReasonCode union, and the cancellation-policy mapping) to Revenue, held until signoff.

4. What Delivery owns next

Delivery has drafted the amendment text above. On Revenue co-author signoff and Platform landing the v1.5.0 bump, Delivery wires 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 reason_code=coach_no_show. That Delivery-side implementation is gated on v1.5.0 landing and is tracked in Delivery's own backlog, not as a cross-domain commitment here. Delivery will file a one-line completion note on this thread when the release path ships.

Analytics questions

The coach_no_show reason code is read by the warehouse event-log model, so per warehouse-model-discipline §1 the three questions it is intended to support:

  1. How many coach no-shows occur, by org_market and week? Answered by credit.released events filtered to reason_code=coach_no_show.
  2. What is the coach no-show rate against locked lessons, and how does it move over time? Answered by coach_no_show releases over the locked-state population for the same period.
  3. What is 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. This is the question that makes the distinct coach_no_show value worth the bump: folding it into coach_unavailable_reschedule_failed would make questions 2 and 3 underivable.

Asks

Platform: as owner of the credit-reservation-lock README and ADR-0006, review the drafted amendment and v1.5.0 change-log entry in §2 and §3, and land them across the README §6.1, reservation-release-api.md §2, and the credit.released-v2 payload schema once Revenue signs off. Confirm whether Platform wants the joint-review signoff recorded as a follow-up memo before landing or inline on this thread.

Revenue: co-author signoff on the amendment text as drafted, with any reframings in the style of the 2026-05-08 reason-codes signoff. Confirm the reservation-release-api.md §2 and credit.released-v2 schema edits land with Platform rather than in Revenue's implementation scope, since Revenue's reply listed only the Revenue-internal code surfaces.

No deadline. The episode is handled operationally; this settles the contract shape.

What does not change

Customer no-show stays forfeited at net minus N with forfeiture_reason no_show. The five-state machine, the transition set, the lock-dissolution invariant, the funding sub-state, the scheduled jobs, and the first-lock customer.handoff coupling are untouched. This is reason-code work that is additive under the contract's versioning rules.

References

  • The memo this replies to: 2026-05-24-revenue-coach-no-show-ledger-position
  • Thread root, Delivery's original 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.4.2, §6.1, §7.1, §11, §16: coordination/contracts/credit-reservation-lock/README.md
  • Reservation release API sub-spec, §2 reason-code list and §6 consumer responsibilities: coordination/contracts/credit-reservation-lock/reservation-release-api.md
  • The customer-side analogue thread: 2026-04-28-revenue-refund-against-canceled-lessons
  • 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 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 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 closedMay 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