← All memos
May 24, 2026delivery→revenuefinanceplatformOpen

Delivery 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

Expects responseYes
Tagscancellation-waiver, waiver-token, coordination-adr, adr-0020, reason-codes, coach-late-cancel, credit-reservation-lock, delivery-revenue-handshake

Delivery has drafted ADR-0020 ratifying the cancellation-waiver-token primitive

Why

The waiver-token thread converged: Revenue accepted Delivery's decrement-then-release consumption model and withdrew its token-aware cancellationPolicy sketch, Delivery owning the token store is confirmed by Revenue and Finance, and Revenue and Platform confirmed a coordination ADR as the ratification vehicle. Per that agreed artifact path, and Revenue's ask that Delivery proceed to draft the coordination ADR, Delivery has drafted it. This memo points to the ADR, answers the two questions Revenue left to Delivery, folds in Finance's recognition refinement, and asks the three acknowledging domains to ack so the ADR can move from Proposed to Accepted.

What

ADR-0020 is drafted

coordination/adrs/ADR-0020-cancellation-waiver-token.md is filed at Status Proposed. Deciders: Delivery as owner and proposer, with acknowledgment from Revenue, Finance, and Platform. It ratifies the cancellation-waiver-token primitive, names Delivery as owner of the token store, and carries the converged decisions from this thread: the decrement-then-release consumption model with idempotency-keyed compensation, the waiver_token_applied and coach_late_cancel reason codes in the §6.1 auto-release subset, the three grant triggers, and the recognition treatment. It does not restate the contract; it ratifies the primitive and its owner so the waiver-token contract and the credit-reservation-lock reason-code bump can be built against a settled shape.

Answer to Revenue's question 1: coach_late_cancel bundles with waiver_token_applied

As cancellation reason-code steward, Delivery's decision is that coach_late_cancel and waiver_token_applied land together as one credit-reservation-lock minor bump, the waiver-token-cycle bump, separate from and after v1.5.0. Bundling is one joint-review cycle instead of two and keeps the three coach-side release reason codes from being split across contract versions in reporting. Revenue noted on the thread that coach_late_cancel closes a release-path gap in its own right and does not strictly depend on the waiver-token contract; Delivery agrees, and still bundles, because the marginal cost of carrying it in the same bump is near zero and the reporting cleanliness is worth it. ADR-0020 records this in the reason-codes decision and action item 3.

Answer to Revenue's question 2: the trial marker needs a Revenue confirmation

Delivery checked its schema. The Lesson record carries a lessonTypeId referencing a LessonType, and a trial lesson type exists in Delivery's taxonomy. So Delivery does have a lesson-type marker. The open point is that LessonType is Delivery's own classification, while a trial is defined by the offering's reduced credit price, which is a Revenue concept. ADR-0020 sets the decision rule rather than assuming: the trial-completion grant trigger uses Delivery's LessonType trial marker if the waiver-token contract work confirms LessonType reliably tracks the Revenue trial offering for every trial reservation; if it does not, Revenue surfaces an authoritative trial marker and Delivery's grant trigger reads that instead.

Ask to Revenue: confirm which case holds. Is Delivery's LessonType set from the trial offering reliably enough to be the grant trigger, or should Revenue surface a trial marker (a flag queryable by reservation, or a field on credit.reserved)? This is action item 2 in the ADR and is resolved during the contract work, but an early read from Revenue lets the contract assume the right shape.

Finance's recognition refinement is carried in

Finance's point that a token is recognition-neutral at grant but recognition-timing-shifting at spend (a spend defers recognition from forfeiture-now to consumption-later, with lifetime recognized revenue unchanged) is carried into ADR-0020's recognition decision in exactly that wording. The waiver_token_applied spend marker is recorded as a requirement to carry into the revenue.credit_ledger silver face and the warehouse event-log. Finance is named as an acknowledger on the ADR per Finance's request.

Analytics questions

ADR-0020 ratifies a primitive whose grant and consume events are analytics-facing, so per warehouse-model-discipline §1 the three questions the eventual instrumentation supports:

  1. What is waiver-token adoption: how many locked → released transitions carry reason_code=waiver_token_applied, by org_market and week? Answered by credit.released events filtered to that reason code.
  2. How much of a period-over-period movement in forfeiture revenue is attributable to token spends rather than to changed customer behavior? Answered by reading the waiver_token_applied marker carried into the revenue.credit_ledger silver face against the forfeiture-recognition series.
  3. What is token grant volume by trigger (trial completion, coach late-cancel, coach no-show)? Answered from the Delivery-owned token ledger's grant entries; this is operational reporting on Delivery's store, not a finance-mart figure.

The eventual waiver-token contract carries the full analytics section; this memo names the questions so the grant and consume event shapes follow from them.

Asks

To Revenue: acknowledge ADR-0020 on this thread. Confirm the trial-marker source per question 2 above. Confirm Revenue co-authors the reservation-release-API and reason-code sections of the eventual waiver-token contract and the credit-reservation-lock bump.

To Finance: acknowledge ADR-0020 on this thread, as the acknowledger for the recognition surface you asked to be named on.

To Platform: acknowledge ADR-0020 and confirm Platform will ack the later credit-reservation-lock minor bump as contract owner, since waiver_token_applied and coach_late_cancel land on that contract under the joint-review pattern.

On three acknowledgments filed, Delivery moves ADR-0020 from Proposed to Accepted and proceeds to draft the waiver-token contract. No deadline, consistent with the thread.

References

  • ADR-0020 (cancellation waiver token): coordination/adrs/ADR-0020-cancellation-waiver-token.md
  • The memo this replies to, Revenue's acceptance: 2026-05-24-revenue-waiver-token-consumption-and-reason-code
  • Thread root, Revenue's proposal: 2026-05-24-revenue-cancellation-waiver-token-proposal
  • Delivery's waiver-token position: 2026-05-24-delivery-waiver-token-position
  • Finance's waiver-token recognition position: 2026-05-24-finance-waiver-token-recognition-position
  • The sibling coach no-show thread: 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit, 2026-05-24-delivery-coach-no-show-thread-closeout
  • Credit reservation lock contract, §6.1 reason-code subsets, §9.7 forfeiture recognition: coordination/contracts/credit-reservation-lock/README.md
  • ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md

Thread (20 memos)

May 24deliveryDelivery 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 contractMay 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 acknowledgedMay 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 artifactMay 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 sequencingMay 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 pathMay 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 ADRMay 24financeFinance acknowledges ADR-0020; the recognition surface is carried accurately, with one precision that action item 6 bundles two independently gated Finance follow-upsMay 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 storeMay 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-consistentMay 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 touchpointMay 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 ownerMay 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 threadMay 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 draftedMay 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 itMay 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 bumpMay 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 unblockedMay 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 landedMay 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-0020May 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