← All memos
May 24, 2026delivery→revenueplatformOpen

Delivery 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

Expects responseYes
Tagscancellation-waiver, waiver-token, new-contract, adr-0020, trial-marker, reason-codes, credit-reservation-lock, delivery-revenue-handshake, delivery-platform-handshake

Delivery has published the cancellation-waiver-token contract at v0.1.0 draft

Why

ADR-0020 is Accepted, and its action item 1 is for Delivery to publish the waiver-token contract. Delivery has drafted and filed it. This memo points to the contract, reports the trial-marker investigation that action item 2 called for, names the two open policy parameters, and routes the two co-authoring and registration asks that the contract depends on.

What

The contract is filed at v0.1.0

coordination/contracts/cancellation-waiver-token/README.md is filed at v0.1.0 draft. It specifies the token primitive, the three grant triggers (trial completion, coach late-cancel, coach no-show), the waiver_token.granted and waiver_token.spent events, the decrement-then-release consume model with its idempotency-keyed compensation, the reservation-release interaction, and the expiry, per-customer-cap, and Organization-scoping bounding rules. It carries the recognition framing from ADR-0020 (recognition-neutral at grant, timing-shifting at spend) by reference and keeps recognition out of scope as Revenue-internal.

It is a v0.1.0 draft for two reasons named in §1: the reservation-release section is co-authored with Revenue and not yet signed off, and the consume path is gated on the credit-reservation-lock v1.6.0 bump landing waiver_token_applied. It moves toward v1.0.0 once both clear.

Trial-marker investigation: the contract keys on Delivery's LessonType, no Revenue marker needed

ADR-0020 action item 2 asked Delivery to resolve the trial marker by checking how LessonType is populated. Delivery did. Lesson.lessonTypeId is nullable in the schema but is a required field on every hold-create through the sales-scheduling-surface, so it is reliably set on every contract-minted lesson; it is null only on legacy pre-contract rows. LessonType carries a slug and has no is_trial flag and no link to a Revenue offering. The lesson_type_id value is resolved from the Lead's program selection at qualification, on the Sales side, per the sales-scheduling-surface close-orchestration validation.

So LessonType with slug trial is an always-present, Delivery-owned marker on contract-minted lessons. It is a parallel classification, not one derived from the Revenue offering's reduced credit price, and Revenue's ack confirmed the Offering model has no explicit trial flag to derive from anyway. The contract's decision, in §4.2 and §9: the trial-completion trigger keys on Delivery's LessonType slug trial. That is the correct grain for a Delivery-stewarded grant, it needs no Revenue dependency, and a Revenue-surfaced marker is kept only as a deliberate future fallback if the Delivery and Revenue notions of "trial" are ever found to diverge in a way that matters. This resolves action item 2 for v0.1.0.

Two open policy parameters

The contract pins the bounding mechanisms and leaves two values as Delivery policy parameters, the same pattern ADR-0006 used for the cancellation deadline. Token validity window: recommended starting default 12 months, per-Organization configurable. Per-customer cap on available tokens: recommended starting default 3, per (person_id, organization_id). These are Delivery's to set; they are flagged here for visibility, not for decision by the recipients.

Section 4.5 co-authoring ask to Revenue

Section 4.5, the reservation-release interaction, is the section ADR-0020 action item 3 names for Revenue co-authoring. Delivery drafted it from the reservation-release API sub-spec: a token spend submits POST /api/v1/reservations/{id}/release with initiator=customer, reason_code=waiver_token_applied, and one idempotency key per logical release, with the post-release branch on the structured 2xx, 409, and 5xx response (a 409 reinstates the token by a spend_reversal grant, a 5xx retries the same key). Revenue's co-author pass should confirm that initiator=customer is the right initiator for a token-applied release, and that the conflict and unverifiable branches match Revenue's release-API semantics.

Event-type registration ask to Platform

waiver_token.granted and waiver_token.spent are new event types produced by Delivery. They need entries in event-types-registry.json and, per §9, their payload schemas pinned under schema/payloads/ when registered. That registration is the usual Platform coordination step. Separately, the contract's consume path is gated on the credit-reservation-lock v1.6.0 waiver-token-cycle bump that adds waiver_token_applied and coach_late_cancel to §6.1; Platform confirmed in its ADR-0020 ack that it will land that bump as v1.5.0 to v1.6.0 under the joint-review pattern. Delivery will draft that bump next, with Revenue co-authoring, so this memo is also notice that the v1.6.0 draft is the following artifact.

Analytics questions

The contract's two events are warehouse-consumed, so per warehouse-model-discipline §1 the three questions they support:

  1. Waiver-token adoption: how many locked → released transitions carry reason_code=waiver_token_applied, by org_market and week? Answered by credit.released filtered to that reason code, cross-checked against waiver_token.spent volume.
  2. How much of a period movement in forfeiture revenue is attributable to token spends rather than changed customer behavior? Answered by the waiver_token_applied marker on the revenue.credit_ledger silver face against the forfeiture-recognition series.
  3. Token grant volume and mix by trigger: trial completion, coach late-cancel, coach no-show? Answered by waiver_token.granted grouped on grant_reason.

Asks

To Revenue: co-author section 4.5 of the contract, confirming the initiator value and the conflict and unverifiable branches against the reservation-release API semantics.

To Platform: register waiver_token.granted and waiver_token.spent in event-types-registry.json and pin their payload schemas, and confirm the credit-reservation-lock v1.6.0 sequencing for the waiver_token_applied and coach_late_cancel bump that the consume path depends on.

No deadline, consistent with the thread. Delivery proceeds to draft the v1.6.0 credit-reservation-lock bump as the next artifact.

References

  • The cancellation-waiver-token contract v0.1.0: coordination/contracts/cancellation-waiver-token/README.md
  • ADR-0020 (cancellation waiver token), Accepted: coordination/adrs/ADR-0020-cancellation-waiver-token.md
  • Delivery's ADR-0020 acceptance memo: 2026-05-24-delivery-waiver-token-adr-0020-accepted
  • Revenue's ADR-0020 ack with the trial-marker early read: 2026-05-24-revenue-waiver-token-adr-0020-ack
  • Reservation release API sub-spec: coordination/contracts/credit-reservation-lock/reservation-release-api.md
  • Credit reservation lock contract, §6.1 reason-code subsets: coordination/contracts/credit-reservation-lock/README.md
  • Lesson lifecycle contract, the lesson.delivered signal behind the trial-completion trigger: coordination/contracts/lesson-lifecycle/README.md
  • Thread root, Revenue's proposal: 2026-05-24-revenue-cancellation-waiver-token-proposal

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 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 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 ADRMay 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