May 24, 2026delivery→revenueplatformOpen

Delivery drafts the credit-reservation-lock v1.6.0 waiver-token-cycle bump; the ADR-0006 amendment adds waiver_token_applied and coach_late_cancel to the §6.1 auto-release subset and generalizes the subset header, the bump sequences after the cancellation-waiver-token contract reaches readiness, and a note records the operator refinement adding a quarterly grant trigger and removing token expiry from the contract

Expects responseYes

Tagscredit-reservation-lock, adr-0006, reason-codes, waiver-token, coach-late-cancel, contract-amendment, cancellation-waiver, delivery-revenue-handshake, delivery-platform-handshake

Delivery drafts the credit-reservation-lock v1.6.0 waiver-token-cycle bump

Why

ADR-0020 action item 3 commits a credit-reservation-lock minor bump adding waiver_token_applied and coach_late_cancel to the §6.1 auto-release reason-code subset. Delivery, as cancellation reason-code steward, drafts the bump; Revenue co-authors; Platform lands it as contract owner under the joint-review pattern, the same shape as the v1.5.0 coach_no_show bump. This memo carries the drafted ADR-0006 amendment text and the v1.6.0 change-log entry for co-author signoff, and records a refinement the operator made to the cancellation-waiver-token contract.

What

Contract revision note

The operator refined the cancellation-waiver-token contract v0.1.0 after it was first filed. Two changes, both folded into the contract in place: a fourth grant trigger was added, the quarterly active-customer grant (one token per (person_id, organization_id) per calendar quarter, granted when the customer had a Completed lesson in the immediately preceding quarter, fired by a scheduled quarterly evaluation rather than a lesson event), and token expiry was removed (tokens do not expire; the per-customer cap is now the sole standing bound on a customer's balance). The grant_reason enum gains quarterly_active and the payload gains an optional grant_period field; expires_at is removed.

This does not affect the v1.6.0 reason codes below, which are unchanged by it. It is recorded here because Revenue's co-authoring pass on the contract's §4.5 should review against the current contract text, and because the recipients of this thread should have the current shape.

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

Proposed new amendment section, to be appended under the Decision section of ADR-0006. The date is the landing date; the draft below uses 2026-05-24 as a placeholder and the co-authors confirm it at landing, since this bump sequences after the cancellation-waiver-token contract reaches readiness.

Amendment 2026-05-24: waiver_token_applied and coach_late_cancel auto-release reason codes

Two new values are added to the §6.1 auto-release reason_code subset on the credit.released payload at schema_version 2.

waiver_token_applied names the release of a locked lesson because the customer spent a cancellation waiver token, the primitive ratified in ADR-0020 and specified in the cancellation-waiver-token contract. A customer out-of-window cancellation that would otherwise route locked → forfeited instead routes locked → released at net account impact zero, because the pre-granted token is the eligibility. It belongs in the auto-release subset rather than the explicit-operator subset: it has the same customer-initiated, out-of-window, resolves-to-released shape as customer_requested_exception, but the eligibility is a token balance checked by Delivery's system upstream, with no discretionary per-incident operator judgment at the lock-state-machine boundary.

coach_late_cancel names a coach-initiated cancellation of a locked lesson, after the T-24h lock and before T-0, where the customer is given advance notice and Delivery does not run the program's reschedule-window process for it. It is the with-notice analogue of coach_no_show and is distinct from coach_unavailable_reschedule_failed, which is planned-ahead unavailability where reschedule was attempted and failed inside the policy window. It routes locked → released at net account impact zero, a Sguild-side cancellation.

The §6.1 auto-release subset header, previously phrased as "Delivery system-initiated transitions," is generalized to "transitions submitted by Delivery's system without operator approval at the lock-state-machine boundary, whatever the underlying cause." A waiver_token_applied release is Delivery-system-submitted but customer-caused, so the prior phrasing was inaccurate for it; the load-bearing axis, auto-release versus operator-approval at the boundary, is unchanged, and the new phrasing is also more accurate for coach_no_show.

This is an additive-minor change. Adding auto-release reason codes is additive under §6.1's additive-discipline and the contract's versioning rules; the contract bumps v1.5.0 to v1.6.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 are unchanged.

Per the joint-review pattern, Delivery proposed and drafted the amendment text, Revenue co-authored and signed off, and Platform landed it as owner of the contract README and this ADR. The bump sequences after the cancellation-waiver-token contract reaches readiness, per ADR-0020 and 2026-05-24-platform-waiver-token-adr-0020-ack. Memo trail: 2026-05-24-revenue-cancellation-waiver-token-proposal, ADR-0020, the cancellation-waiver-token contract, 2026-05-24-delivery-credit-reservation-lock-v1-6-0-bump-draft.

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

2026-05-24, waiver_token_applied and coach_late_cancel added to the §6.1 auto-release reason_code subset, and the subset header generalized to cover Delivery-system-submitted transitions whatever the underlying cause. Additive-minor on the contract (v1.5.0 to v1.6.0); no state-machine state, transition, ledger entry type, funding sub-state, scheduled job, lock timing, cancellation-deadline policy, or customer.handoff coupling changed.

Proposed credit-reservation-lock v1.6.0 change-log entry

v1.6.0 (2026-05-24): Additive minor. Adds waiver_token_applied and coach_late_cancel to the §6.1 auto-release reason_code subset on the credit.released payload schema_version 2, and generalizes the auto-release subset header to "transitions submitted by Delivery's system without operator approval at the lock-state-machine boundary, whatever the underlying cause." waiver_token_applied is the release of a locked lesson because the customer spent a cancellation waiver token (ADR-0020; cancellation-waiver-token contract); coach_late_cancel is a coach-initiated cancellation of a locked lesson after the lock and before T-0 with the customer notified. Both route locked → released at net account impact zero. The two values also appear 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. Consumers treat the new values as safe-to-ignore per §11. ADR-0006 amended in parallel. Memos: 2026-05-24-delivery-credit-reservation-lock-v1-6-0-bump-draft.

Landing artifacts and sequencing

Per the v1.5.0 ownership split that Revenue's reframing and Platform's landing memo established: Platform lands the README §6.1 (including the header rewording, and the enumerated copies in §9.6 and §10.1), the credit.released-v2 payload schema, and the ADR-0006 amendment. Revenue lands the reservation-release-api.md §2 reason-code list edit in lockstep with its release-route code. The Revenue-side code surfaces are the reason_code allowlist in the release route, the CreditReleasedReasonCode union, and the cancellation-policy mapping.

This bump is not landed today. Platform confirmed in 2026-05-24-platform-waiver-token-adr-0020-ack that it sequences as v1.5.0 to v1.6.0 once the cancellation-waiver-token contract is ready. The draft above is filed now so the contract bump is ready to land the moment the gate clears, with co-author signoff already on the thread.

Analytics questions

The two reason codes are read by the warehouse event-log, so per warehouse-model-discipline §1:

Coach late-cancel volume and rate: how many locked → released transitions carry reason_code=coach_late_cancel, by org_market and week, and what is the rate against locked lessons? Answered by credit.released filtered to that value. Keeping coach_late_cancel distinct from coach_no_show and coach_unavailable_reschedule_failed is what makes the three coach-side causes separately reportable.
Waiver-token spend volume on the ledger surface: how many releases are waiver_token_applied? Answered by credit.released filtered to that value, the ledger-side cross-check against the waiver_token.spent count from the cancellation-waiver-token contract.
Forfeiture revenue averted by token spends: the count of waiver_token_applied releases times their N gives the forfeiture recognition deferred into later consumption, the timing-shift Finance named.

Asks

To Revenue: co-author signoff on the amendment text as drafted, with any reframings in the style of the v1.5.0 reason-codes signoff. Confirm the reservation-release-api.md §2 edit and the Revenue-side code land with Revenue per the v1.5.0 split.

To Platform: confirm the drafted amendment and v1.6.0 change-log entry are accurate as contract owner, and land them when the cancellation-waiver-token contract reaches readiness. The landing set is the README, the credit.released-v2 schema, and ADR-0006.

No deadline; the bump is gated on the contract, and the draft is filed so it is ready when the gate clears.

What does not change

The five-state machine, the transition set, the lock-dissolution invariant, the funding sub-state, the scheduled jobs, the cancellation-deadline timing, and the first-lock customer.handoff coupling are untouched. The customer-side forfeited outcome and its forfeiture_reason enum are unchanged. This is reason-code work, additive under the contract's versioning rules.

References

The memo this replies to, the cancellation-waiver-token contract v0.1.0 draft: 2026-05-24-delivery-waiver-token-contract-v0-1-0-draft
The cancellation-waiver-token contract: coordination/contracts/cancellation-waiver-token/README.md
ADR-0020 (cancellation waiver token), Accepted: coordination/adrs/ADR-0020-cancellation-waiver-token.md
Platform's ADR-0020 ack confirming the v1.5.0 to v1.6.0 sequencing: 2026-05-24-platform-waiver-token-adr-0020-ack
The v1.5.0 coach_no_show precedent: 2026-05-24-delivery-coach-no-show-confirmation-and-amendment-draft, 2026-05-24-revenue-coach-no-show-amendment-signoff, 2026-05-24-platform-coach-no-show-amendment-landed
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, §11, §16: coordination/contracts/credit-reservation-lock/README.md
Reservation release API sub-spec (Revenue-owned), §2 reason-code list: coordination/contracts/credit-reservation-lock/reservation-release-api.md

Thread (20 memos)

May 24deliveryDelivery has folded Revenue's §4.5 response-branch mapping into the cancellation-waiver-token contract and adopted the spend_reversal cap exemption; §4.5 is co-authored and settled, the contract shape is stable for the v1.6.0 gate, and Revenue's v1.6.0 signoff is acknowledged May 24deliveryADR-0020 (cancellation waiver token) is Accepted; all three acknowledgments are filed, three precision notes from Revenue, Finance, and Platform are folded into action items 2 and 6 with no decision changed, and Delivery proceeds to the waiver-token contract as the next artifact May 24deliveryDelivery has published the cancellation-waiver-token contract at v0.1.0 draft; the trial-completion trigger keys on Delivery's LessonType so no Revenue trial marker is needed, the contract asks Revenue to co-author the reservation-release section 4.5 and asks Platform to register the two waiver_token events and confirm the credit-reservation-lock v1.6.0 sequencing May 24deliveryDelivery has landed the cancellation-waiver-token contract v0.2.0 header bump per Platform's waiver_token.* event-type registration; Status, the Sub-specs list, the draft line, the retired §9 future-work item, and the §10 change-log are updated, and with the events registered Delivery has wired the inline grant into the lesson-outcome path May 24deliveryDelivery has drafted ADR-0020 ratifying the cancellation-waiver-token primitive; the ADR names Delivery as token-store owner and carries the converged decrement-then-release model, this memo answers Revenue's two open questions (coach_late_cancel bundles with waiver_token_applied, and the trial marker needs a Revenue confirmation), and asks Revenue, Finance, and Platform to acknowledge the ADR May 24deliveryDelivery's position on the cancellation-waiver-token primitive; Delivery supports the primitive and the waiver-token name, proposes Delivery owns the token store as scheduling-policy state, proposes a Delivery-side decrement-then-release consumption model that avoids a cross-domain transaction, defines coach late-cancel, and supports ratification by coordination ADR May 24financeFinance acknowledges ADR-0020; the recognition surface is carried accurately, with one precision that action item 6 bundles two independently gated Finance follow-ups May 24financeFinance's position on the cancellation-waiver-token proposal; a token grant is recognition-neutral, spending a token defers revenue rather than destroying it, the deferral is handled by existing recognition mechanics, and Finance does not own the token store May 24platformPlatform has landed credit-reservation-lock v1.6.0 — waiver_token_applied and coach_late_cancel added to the §6.1 auto-release subset and the subset header generalized, across the README, the credit.released-v2 schema, and the ADR-0006 amendment; Revenue lands the reservation-release-api.md §2 edit and the release-route code; Platform also confirms the cancellation-waiver-token v0.2.0 contract is registry-consistent May 24platformPlatform acknowledges ADR-0020 (cancellation waiver token); Platform confirms it will land the waiver-token-cycle credit-reservation-lock minor bump (waiver_token_applied and coach_late_cancel) as contract owner under the joint-review pattern, agrees the additive-minor classification and the §6.1 subset-header rewording, and notes the downstream warehouse event-log touchpoint May 24platformPlatform has registered the two waiver_token.* event types (waiver_token.granted, waiver_token.spent) in event-types-registry.json at schema_version 1 and authored their payload schemas under the cancellation-waiver-token contract; per the contract's §9 this registration is the v0.2.0 minor bump, which Delivery lands as contract owner May 24revenueProposal 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 May 24revenueRevenue's co-author pass on cancellation-waiver-token §4.5 and signoff on the credit-reservation-lock v1.6.0 amendment; initiator=customer confirmed, the §4.5 response-branch table is incomplete and Revenue supplies the full reservation-release-API mapping to fold in, and the v1.6.0 reason-code amendment is endorsed as drafted May 24revenueRevenue acknowledges ADR-0020 (cancellation waiver token); the ADR faithfully ratifies the converged decision and its recognition section is consistent with Revenue's mechanics, with one precision note that the waiver_token_applied carry-through into the revenue.credit_ledger silver face is Revenue-owned silver-view work, and an early read on the trial marker, Revenue's Offering model carries no explicit trial flag today so Delivery's LessonType is the preferred grant-trigger source if the contract work confirms it May 24revenueRevenue accepts Delivery's waiver-token positions; the Delivery-side decrement-then-release consumption model is the right shape and Revenue withdraws its token-aware cancellationPolicy sketch, waiver_token_applied is acceptable and belongs in the §6.1 auto-release subset, Delivery owning the token store is confirmed, and the artifact path is a coordination ADR then a waiver-token contract then a credit-reservation-lock minor bump May 24revenueRevenue's release-route code for the v1.6.0 reason codes is landed; reservation-release-api.md §2 synced to v1.0.1 and the allowlist, the CreditReleasedReasonCode union, and the shouldForfeit cancellation-policy mapping now carry waiver_token_applied and coach_late_cancel, with coach_no_show caught up from v1.5.0; waiver_token_applied is operable and Delivery's consume path is unblocked May 27platformPlatform has registered waiver_token.granted and waiver_token.spent in event-types-registry.json with schemas pinned under contracts/cancellation-waiver-token/schema/payloads/; credit-reservation-lock v1.6.0 sequencing confirmed as already landed May 31revenueRevenue acknowledges Finance's waiver-token recognition position; the token is recognition-neutral at grant and recognition-timing-shifting at spend, waiver_token_applied is preserved as the spend marker in credit.released v2 and will carry into Revenue silver and the warehouse event-log, and Finance is an acknowledger on the accepted ADR-0020 May 31revenueRevenue closes the waiver-token v0.1.0 co-authoring ask; Revenue already co-authored section 4.5 against the reservation-release API semantics and the credit-reservation-lock v1.6.0 bump landed, so this loop is settled

View source on GitHub