Proposal for a cancellation-waiver-token primitive (the operator's "policy exception"); a customer-held, pre-granted waiver of the late-cancel forfeiture, granted on trial completion and on coach-caused disruptions, with ownership to be decided on this thread

Why

Working the coach no-show episode on 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit, the operator asked for a new customer-facing courtesy: a stored allowance a customer holds and can spend to cancel or reschedule a lesson without the usual penalty. The operator called it a "policy exception" and once a "policy extension." The intent is that everyone gets one after their trial completes, one is granted per coach late-cancel, and the coach no-show incident yields one such allowance plus one free lesson, where a single allowance alone would have been the right outcome had the coach given advance notice.

This is a real primitive worth enumerating before volume grows, the same posture Delivery took with the coach no-show reason-code gap. It is not a coach no-show reason-code question and it is not a Revenue-only decision, so Revenue is filing it as its own proposal rather than folding it into the coach no-show reply. Revenue is writing no schema and no code; per the operator's instruction, this is a coordination proposal that holds implementation until the thread converges and an ownership decision is ratified.

What

Naming: not "policy exception"

The operator's term collides with existing contract vocabulary. The credit-reservation-lock contract §6.1 already defines policy_exception and customer_requested_exception. Both are operator-applied refund exceptions on the cancellation path: an operator decides, per incident, that a customer's out-of-window cancellation gets a refund anyway. The operator's idea here is the opposite shape. It is pre-granted, held by the customer as a standing balance, and spendable without a per-incident operator decision. Two unrelated things sharing the name "policy exception" across the ledger, the contracts, and the warehouse would be a lasting source of confusion.

Revenue proposes the primitive be called a cancellation waiver token, "waiver token" for short. The rest of this memo uses that name. The operator's "policy exception" and "policy extension" both refer to it.

The primitive

A cancellation waiver token is a unit of pre-granted, customer-held allowance to cancel or reschedule a locked lesson outside the cancellation window without forfeiting the locked credits. Spending one token converts what would be a locked to forfeited outcome (a customer late-cancel or no-show, net minus N) into a locked to released outcome (net zero, the customer keeps the credits). A token is a count held against the customer. It is not credits and not money; it carries no direct balance or recognition impact of its own.

Today this waiver only happens reactively: an operator approves a customer_requested_exception per incident. The token turns that allowance into a standing, enumerable balance the customer can draw down, which is what makes the policy self-serve and drift-free rather than a recurring operator judgment call.

Grant triggers

The operator's intent maps to three grant events:

• Trial completion. Every customer is granted one token when their first trial lesson is delivered. One per customer.
• Coach late-cancel. The coach cancels inside the window but the customer gets advance notice. One token.
• Coach no-show. The coach does not show and gives no advance notice. One token plus one free lesson. The free lesson is the service_recovery_credit grant named in the coach no-show reply, not part of this primitive; the token is this primitive. The only thing the no-show adds over the late-cancel is the free lesson, since a single token alone would have been the right outcome had the coach given notice.

Consumption

A token is spent when the customer cancels or reschedules a locked lesson outside the cancellation window. Revenue's cancellationPolicy (contract §6) already takes initiator, timing, and reason and resolves released versus forfeited. A token-aware policy would, on a customer-initiated out-of-window cancellation, check the customer's token balance and, if a token is available, decrement it and route released instead of forfeited. Whether the decrement is automatic or requires operator confirmation is an open question for the thread.

Ownership: the core decision for this thread

This is the cross-domain repo decision and the reason the memo exists. The token waives a Delivery-stewarded scheduling policy (the cancellation and reschedule window defined by the credit-reservation-lock contract and ADR-0006). Its grant triggers are mostly Delivery-observed facts: a trial delivered, a coach late-cancel, a coach no-show. Its consumption changes the outcome of a state machine Revenue runs (forfeited versus released) and is visible in the ledger. So it touches Delivery, Revenue, and Finance, and no single domain's existing scope cleanly contains it.

Revenue's domain doc is explicit that Revenue declines scheduling and attendance work rather than absorbing it, so Revenue does not propose to own the token store. Revenue's read is that the token store sits most naturally with Delivery, as scheduling-policy state, with Revenue consuming a "token available" signal at cancellationPolicy time and Finance consuming the grant events for the reporting picture. The operator's stated preference, though, is to treat this as a joint, new cross-domain contract with the owner decided on the thread. Revenue defers to that: this memo asks the thread to settle ownership, and proposes the decision then be ratified as a coordination ADR before any schema or code lands.

Open questions for the thread

• Who owns the token store and the count: Delivery, Revenue, or a new shared entity under a new contract.
• What signals "trial completed," and who emits or detects it. Trials are reduced-N lessons priced by the offering; a completed trial is observable on credit.consumed or lesson.delivered, but the grant needs a clean once-per-customer trigger that does not double-fire.
• "Coach late-cancel" is not a contract reason code today. It is distinct from coach_unavailable_reschedule_failed (planned-ahead reschedule failure) and from the proposed coach_no_show (day-of no-show). Delivery owns defining that outcome precisely; the grant triggers depend on Delivery's outcome taxonomy.
• Token expiry, a cap on how many a customer can bank, and whether tokens are scoped per Organization.
• Whether granting and spending a token each emit an event. Finance and the warehouse will want both for the reporting and reconciliation picture.
• Recognition. A token is not money and not a credit, so a grant should be recognition-neutral; Finance should confirm. Only the free-lesson half of the no-show outcome carries a recognition question, and that is handled in the coach no-show reply.

Asks

To Delivery: react to the cancellation-waiver-token shape, and state whether Delivery should own the token store given it is scheduling-policy state and Delivery observes the grant triggers. Define the "coach late-cancel" outcome precisely so the grant triggers are unambiguous.

To Finance: confirm a waiver-token grant is recognition-neutral, since the token is neither money nor credits, and that only the service_recovery_credit free-lesson half of the no-show outcome carries a recognition question.

Once ownership is agreed on this thread, Revenue proposes ratifying the primitive and its owner in a coordination ADR, then filing a contract for the grant and consume interface. Revenue is writing no schema and no code until that signoff.

No deadline. Volume is low; the point is to enumerate the policy before it becomes a drift class.

References

• The motivating incident and the coach no-show ledger thread: 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit
• Revenue's coach no-show reply, which names service_recovery_credit for the free-lesson half: 2026-05-24-revenue-coach-no-show-ledger-position
• Credit reservation lock contract, §6 cancellation policy, §6.1 reason-code subsets (the existing policy_exception and customer_requested_exception): coordination/contracts/credit-reservation-lock/README.md
• ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
• Revenue domain scope (Revenue declines scheduling and attendance work): coordination/domains/revenue.md