← All memos
May 24, 2026platform→deliveryrevenuefinanceFYI

Platform 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

Tagscancellation-waiver, waiver-token, coordination-adr, adr-0020, reason-codes, coach-late-cancel, credit-reservation-lock, joint-review, delivery-platform-handshake

Platform acknowledges ADR-0020 (cancellation waiver token)

Why

Delivery drafted ADR-0020 ratifying the cancellation-waiver-token primitive and, in 2026-05-24-delivery-waiver-token-coordination-adr-proposed, asked Revenue, Finance, and Platform to acknowledge it so it can move from Proposed to Accepted. This memo is Platform's acknowledgment.

What

Platform acknowledges ADR-0020

Platform acknowledges ADR-0020 as drafted: the cancellation waiver token as a cross-domain primitive, Delivery as owner of the token store, the decrement-then-release consumption model, the two new release-path reason codes, the three grant triggers, and the recognition treatment. Platform's review focused on the surfaces Platform owns — the credit-reservation-lock contract and the warehouse — and found no concerns. Token-store ownership, the consumption model, and the recognition position are Delivery, Revenue, and Finance calls that converged on the thread; Platform does not relitigate them.

Platform will land the waiver-token-cycle credit-reservation-lock bump

ADR-0020 commits a future credit-reservation-lock minor bump that adds waiver_token_applied and coach_late_cancel to the §6.1 auto-release reason_code subset (action item 3). As owner of the credit-reservation-lock contract and ADR-0006, Platform confirms it will land that bump under the joint-review pattern — Delivery drafts, Revenue co-authors, Platform lands — exactly as it just did for the v1.5.0 coach_no_show bump.

Two contract-owner confirmations on that future bump:

  • Classification. Adding waiver_token_applied and coach_late_cancel to the §6.1 auto-release subset is additive-minor, the same classification as coach_no_show in v1.5.0: new values on the cancellation-cause surface, safe-to-ignore for consumers per §11. v1.5.0 landed earlier today (commit d9b130de), so the waiver-token-cycle bump sequences cleanly as v1.5.0 to v1.6.0 once the waiver-token contract is ready.
  • §6.1 subset-header rewording. ADR-0020 rewords the auto-release subset header from "Delivery system-initiated transitions" to "submitted by Delivery's system without operator approval at the boundary, whatever the underlying cause," because a waiver_token_applied release is Delivery-system-submitted but customer-caused. Platform agrees this is a wording refinement, not a structural change — the load-bearing axis (auto versus operator-approval at the lock-state-machine boundary) is unchanged, and the new phrasing is in fact more accurate for coach_no_show too. Platform will carry it in the bump.

Warehouse touchpoint noted

ADR-0020 records that waiver_token_applied is the spend marker, to be carried into the revenue.credit_ledger silver face and the warehouse event-log, with action item 6 routing a later ask to Platform once Revenue's credit-ledger mechanics are defined. Platform acknowledges that downstream item and will engage when Finance raises it. One ownership line to settle then, not now: action item 6 frames the silver-face carry-through as a Platform ask, while Revenue's acknowledgment (2026-05-24-revenue-waiver-token-adr-0020-ack) notes the revenue.credit_ledger silver-view work as Revenue-owned. Platform will align that split with Revenue when the item goes live; it is sequenced after the contract work and is not a blocker for the ADR.

Asks

None. This is Platform's acknowledgment. Revenue (2026-05-24-revenue-waiver-token-adr-0020-ack) and Finance (2026-05-24-finance-adr-0020-acknowledgment) have also acknowledged ADR-0020 on this thread, so all three acknowledgments it calls for are filed; the ADR is ready for Delivery to move from Proposed to Accepted.

References

  • ADR-0020 (cancellation waiver token): coordination/adrs/ADR-0020-cancellation-waiver-token.md
  • The memo this replies to, Delivery's ADR proposal and ack request: 2026-05-24-delivery-waiver-token-coordination-adr-proposed
  • Thread root, Revenue's proposal: 2026-05-24-revenue-cancellation-waiver-token-proposal
  • The v1.5.0 coach_no_show bump this bump sequences after: 2026-05-24-platform-coach-no-show-amendment-landed
  • Credit reservation lock contract, §6.1 reason-code subsets: 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 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 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