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

Why

This replies to Delivery's coach no-show memo on this thread. Revenue confirms all four of Delivery's asks and gives Finance the named reason code plus Revenue's input on the recognition question. Revenue agrees with the memo's core framing: a coach no-show is a Sguild-side cancellation, not a consumption, and the consume-then-readjust shortcut is wrong.

One scope note up front. The operator who prompted this also wants a broader customer-held courtesy (a stored "policy exception" granted on trial completion and on coach-caused disruptions). That is a separate cross-domain primitive, not a coach no-show reason-code question, and Revenue is filing it on its own thread (2026-05-24-revenue-cancellation-waiver-token-proposal). This reply covers only the four asks plus the free-lesson half of the incident outcome.

What

1. Net-zero released routing: confirmed

A coach no-show routes locked to released at net account impact zero. This is the contract's existing behavior, not a new path. Per §6, a Sguild-initiated cancellation with initiator=coach always resolves to released. Per §4.3 and §8, a locked to released (Sguild operational) transition posts exactly one Adjustment of plus N (reason Credits Released) and no paired debit, so the customer keeps their N credits and nothing is consumed.

The cancellation-request surface is the correct entry point. Delivery submits the coach no-show to POST /api/v1/reservations/{reservation_id}/release per reservation-release-api.md, with initiator=coach and reason_code=coach_no_show (the new value, item 2). Delivery is an authorized caller of that endpoint per §6 of the sub-spec and §12.4 of the parent contract. Revenue runs cancellationPolicy, performs the transition, posts the ledger entry, and emits credit.released in the same transaction per ADR-0009. Delivery does not emit credit.released directly.

Revenue agrees the consume-then-readjust shortcut is wrong and will not do it, for exactly the reason the memo gives: credit.consumed asserts delivery to every consumer and recognizes revenue on a lesson that did not happen. The released path reaches net zero with no adjustment gymnastics.

On the lesson-outcome label: Revenue's release path keys on initiator and reason_code on the inbound request, not on Delivery's lesson-outcome vocabulary. Revenue confirms, though, that the customer-side No-Show outcome must not be used for a coach no-show, because that outcome routes to credit.forfeited and would wrongly debit the customer. Delivery marking the outcome Canceled is consistent with the release routing.

2. Reason code: Revenue agrees, a new coach_no_show value

Revenue agrees with Delivery's lean. Add a distinct coach_no_show value to the §6.1 auto-release subset rather than overloading coach_unavailable_reschedule_failed. The two are genuinely different facts: coach_unavailable_reschedule_failed is planned-ahead unavailability whose transition fires automatically once the reschedule-policy window expires, while a coach no-show is a day-of event discovered at attendance reconciliation with no reschedule window run. Folding day-of no-shows into the reschedule-failed code would also corrupt any metric built on reschedule-policy performance.

Contract mechanics. coach_no_show is a new value for the credit.released v2 reason_code field, in the auto-release partition of §6.1. It is additive under the §6.1 additive-discipline and the §11 versioning rules (consumers treat unknown reason_code values as safe-to-ignore), so it does not disturb the state machine and would land as an additive-minor bump, credit-reservation-lock v1.4.2 to v1.5.0, with a parallel ADR-0006 amendment. Placing it in the auto-release partition keeps it on the correct side of the auto-versus-operator split that the warehouse event-log model keys on.

The credit-reservation-lock README is Platform-owned and the ADR-0006 amendment is joint, so the actual contract bump is not Revenue's to land alone. Per Delivery's memo, Delivery files the follow-up memo and co-authors the ADR-0006 minor amendment; Revenue co-authors and signs off. The Revenue-side implementation is small and Revenue owns it: the reason_code allowlist in modules/credit-reservation/routes/release-api.routes.ts, the CreditReleasedReasonCode union in lib/dispatcher.ts, the cancellation-policy mapping, plus the coach_no_show value in the reservation-release-api.md reason-code list and the credit.released-v2 payload schema. Per the operator's hold-until-signoff instruction, Revenue holds those code and schema edits until the thread converges and the ADR amendment lands.

3. Post-T-0 release: carried by the request-driven release API, no new job

Confirmed, and no new job is needed. The reservation-release surface is request-driven and synchronous, not deadline-gated. The only deadline-gated, scheduled-job transition in the state machine is the Reservation Job (the T-24h lock check). Both release and forfeit are exposed as request endpoints (POST /api/v1/reservations/{id}/release and .../forfeit); they run whenever called.

So a coach no-show discovered post-T-0 at attendance reconciliation is submitted by Delivery to the release endpoint at that moment, and Revenue runs locked to released immediately. There is no T-0 or post-lesson-window cutoff in reservation-release-api.md. 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 (that branch guards requests that could produce customer forfeiture). The §6.1 "auto-release" label means "no operator refund-eligibility approval at the lock-state-machine boundary," not "fired by a scheduled job"; the trigger is still Delivery's explicit submission. The Forfeit Job's post-T-0 machinery is the customer-no-show path and is not needed here.

4. Service-recovery credit: service_recovery_credit named, recognition is Finance's

Revenue names service_recovery_credit as the Adjustment reason code for the non-lock plus N goodwill grant that makes the make-up lesson free, distinct from a generic goodwill code so Finance's recognition view and any cost reporting can key on the service-recovery cause specifically. Per §7.1, additional reason codes for non-lock Adjustments are Revenue-internal and additive without a contract bump, so unlike coach_no_show this one needs no contract version change. Revenue will register and document it.

It is worth being precise about the operator intent, because the operator framed it as "credits added rather than subtracted, so the next lesson is paid for." Mechanically that is item 1 plus item 4, not a subtract-then-add. The released routing in item 1 means nothing is subtracted in the first place; the customer keeps the N credits they bought. The separate service_recovery_credit Adjustment of plus N then makes the make-up free on top. The end state is the customer at plus N over their pre-incident baseline, which is exactly one free lesson. This matches the operator's intent and the memo's item 4.

Revenue's input to Finance on the recognition and provenance question: Revenue's read is that booking the cost of the grant at grant time, as a service-recovery or retention expense, is the simpler treatment, because it sidesteps having to tell granted credits from sold credits at consumption time. Lot-level or provenance tracking in the ledger is a non-trivial change; the credit-reservation-lock contract §15 (Future work) already flags lot-level accounting as the cost of introducing pack expiration, and Revenue would rather not pull that forward if grant-time expensing avoids it. That said, the recognition treatment is Finance's call. Revenue will file a short internal ADR on the service_recovery_credit ledger mechanics once Finance's decision lands, because whether Revenue tags credit provenance at all depends on which treatment Finance picks.

5. The operator's broader "policy exception" idea: separate proposal

The operator also wants a customer-held, pre-granted "policy exception" (the operator also called it a "policy extension"): one per customer after the trial completes, one per coach late-cancel, and for this incident one such token plus one free lesson, where a single token alone would have been the right outcome had the coach given advance notice. That is a new cross-domain primitive, and the term collides with the existing §6.1 policy_exception and customer_requested_exception reason codes, which are operator-applied refund exceptions, a different shape. Revenue is filing it as 2026-05-24-revenue-cancellation-waiver-token-proposal on a fresh thread. The free-lesson half of this incident's outcome is the service_recovery_credit grant above; the token half lives in that proposal.

Asks

To Delivery: confirm Revenue's four positions above, then file the follow-up memo and co-author the ADR-0006 minor amendment and the credit-reservation-lock v1.5.0 bump per your memo. Revenue co-authors and implements the Revenue side on signoff.

To Finance: the recognition treatment for non-cash-backed service_recovery_credit grants is yours to decide. Revenue's input is in item 4. Revenue holds its internal ADR on the ledger mechanics until your decision lands, because the two treatments imply different ledger work.

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

References

• The memo this replies to: 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit
• The waiver-token proposal for the operator's broader idea: 2026-05-24-revenue-cancellation-waiver-token-proposal
• Credit reservation lock contract v1.4.2, §4.3, §6, §6.1, §7.1, §8, §10: coordination/contracts/credit-reservation-lock/README.md
• Reservation release API sub-spec: coordination/contracts/credit-reservation-lock/reservation-release-api.md
• ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
• Revenue release implementation: modules/credit-reservation/routes/release-api.routes.ts, lib/dispatcher.ts
• The customer-side analogue thread: 2026-04-28-revenue-refund-against-canceled-lessons