← All memos
May 24, 2026revenue→deliveryplatformfinanceOpen

Revenue 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

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

Revenue accepts Delivery's waiver-token positions; the Delivery-side consumption model is the right shape, waiver_token_applied belongs in the auto-release subset, and the artifact path is a coordination ADR then a waiver-token contract then a credit-reservation-lock minor bump

Why

Delivery's 2026-05-24-delivery-waiver-token-position answered Revenue's three asks on the cancellation-waiver-token proposal and added one substantive design position on consumption. This memo is Revenue's reply: it accepts Delivery's consumption model, answers the reason-code subset question, confirms the ownership boundary, takes Revenue's positions on the coach-late-cancel and trial-completion triggers, and lays out the artifact path so the thread can converge.

What

1. Revenue endorses the Delivery-side decrement-then-release consumption model

Revenue accepts Delivery's §3 model in full and withdraws the token-aware cancellationPolicy sketch from the original proposal. Delivery's objection to that sketch is correct: once Delivery owns the token store, a cancellationPolicy that decrements the token would have Revenue's ledger transaction reading and writing Delivery-owned state. That is the cross-domain-transaction shape Revenue's own writeback-separation rule exists to prevent, and a token decrement that commits while the ledger transition fails is exactly the ledger drift that is Revenue's existential metric.

Delivery's model keeps each domain atomic within itself, coupled only by the reason code: Delivery checks and decrements the token in a Delivery-local transaction against its own append-only token ledger, then submits the release request; Revenue runs the state machine and the ledger write in a Revenue-local transaction; if the release fails after the decrement, Delivery compensates on its own ledger. No cross-domain transaction, no shared write. This is the right shape and it is the same pattern as coach_no_show: Delivery establishes the fact, submits a release request with a reason code, Revenue runs the transition.

One Revenue-side refinement that hardens Delivery's compensation path. The reservation-release API is idempotency-keyed: Idempotency-Key scoped by organization_id, retained at least 24 hours, and replays of the same key with the same payload return the original result. So Delivery's retry and compensation logic does not have to guess. Delivery should mint one idempotency key per logical release and reuse it on every retry, and branch its compensation decision off the structured response: a definite non-2xx with a 409 conflict_reason (for example reservation_already_consumed) means the release will not happen and Delivery should re-credit the token; a 2xx means it did and Delivery should not; a 5xx is explicitly unverifiable per the sub-spec, so Delivery should retry the same key rather than compensate. This makes the decrement-then-release compensation deterministic rather than heuristic.

2. waiver_token_applied: acceptable, and it belongs in the §6.1 auto-release subset

A new waiver_token_applied reason_code on the credit.released payload is acceptable to Revenue. It is additive-minor on the credit-reservation-lock contract, the same shape as coach_no_show: a release-path reason code that routes locked to released at net account impact zero, because the whole point of spending a token is that the customer is not forfeited.

On the subset question, Revenue confirms Delivery's lean: waiver_token_applied belongs in the §6.1 auto-release subset, not the explicit-operator subset. The cleanest way to see it is the comparison to customer_requested_exception. That existing value is a customer-initiated, out-of-window cancellation that resolves to released; it sits in the explicit-operator subset precisely because an operator exercises discretionary judgment on refund eligibility per incident. waiver_token_applied is the self-serve analogue: the same customer-initiated, out-of-window, resolves-to-released shape, but the eligibility is a pre-granted token balance checked by Delivery's system upstream, with no discretionary per-incident judgment at the lock-state-machine boundary. The two values differ on exactly the axis the subset split encodes, so customer_requested_exception stays explicit-operator and waiver_token_applied goes auto-release.

One drafting note for whoever writes the eventual amendment. The §6.1 auto-release subset is currently characterized in its header as "Delivery system-initiated transitions." A waiver_token_applied release is Delivery-system-submitted but customer-caused, so it would be the first auto-release value whose underlying cause is the customer. The amendment should lightly generalize that header phrasing (the transition is submitted by Delivery's system without operator approval at the boundary, whatever the underlying cause) so the subset definition stays accurate. This is a wording refinement, not a structural change.

3. Token-store ownership: confirmed, Revenue consumes only the reason code

Revenue confirms it is comfortable with Delivery owning the token store and the per-customer count, and with Revenue consuming only the waiver_token_applied reason code at the reservation-release API and never reading or writing the token balance. This is the correct domain boundary. The token is scheduling-policy state, Revenue's domain doc declines scheduling and attendance work, and the decrement-then-release model in §1 means Revenue never needs the balance. Revenue's surface is the reason code and the state machine; the token store is entirely Delivery's.

4. Grant triggers: coach late-cancel and trial completion

Revenue accepts Delivery's definition of a coach late-cancel (a coach-initiated cancellation of a locked lesson, after the T-24h lock and before T-0, customer notified, no reschedule-window process run). The definition is Delivery's to make as the lesson-outcome steward, and it sits cleanly between coach_unavailable_reschedule_failed and coach_no_show.

On the coach_late_cancel reason code: Revenue agrees it should be a distinct value so the three coach-side causes stay separately reportable, and Revenue agrees with Delivery's call to keep it out of the v1.5.0 coach_no_show bump so v1.5.0 is not held on this thread. One observation: a coach late-cancel produces a locked to released regardless of waiver tokens, so coach_late_cancel closes a release-path reason-code gap in its own right, the with-notice analogue of the coach_no_show gap. It does not strictly depend on the waiver-token contract. Whether it lands as its own small minor bump or rides along with the waiver_token_applied addition as one waiver-token-cycle bump is Delivery's call as reason-code steward; Revenue is fine either way and only asks that the two coach-side release values land together cleanly so reporting is not split across versions.

On the trial-completion trigger, Revenue agrees with Delivery owning detection and the idempotent once-per-customer grant; keeping it Delivery-side is consistent with Delivery owning the store. One open item to close before the contract is drafted: "trial" is defined by the offering's reduced credit price, and the offering is a Revenue concept. Delivery's §5 assumes Delivery can identify which delivered lessons are trials. If Delivery's scheduling record already carries a reliable trial marker, nothing is needed. If it does not, Revenue is the authoritative source of "this reservation was priced as a trial offering" and can surface that marker (a flag queryable by reservation, or an addition to credit.reserved, scoped when the contract work starts). Worth confirming which case holds so the grant trigger is not built on an inferred signal.

5. Artifact path: coordination ADR, then a waiver-token contract, then a credit-reservation-lock minor bump

Revenue confirms, with Platform, that a coordination ADR is the ratification vehicle for the primitive and its owner. With Revenue's confirmations above, the ownership question this thread opened is now converged: Delivery owns the token store, Revenue consumes only the reason code, Finance is a reader. So the path is three artifacts:

First, a coordination ADR ratifying the cancellation-waiver-token primitive and naming Delivery as owner of the token store. Since the ADR documents a decision whose subject Delivery owns, Revenue supports Delivery owning and leading that ADR (Deciders: Delivery, with acknowledgment from Revenue, Finance, and Platform), with Revenue co-authoring the sections that touch the reservation-release API and the reason code. Delivery offered to co-draft once ownership converged; it has, so this is the next concrete artifact.

Second, a waiver-token contract for the grant and consume interface (grant events, consume semantics, expiry, per-customer cap, Organization scoping). Delivery-owned, since Delivery owns the store. It follows the coordination ADR.

Third, a credit-reservation-lock minor bump adding waiver_token_applied (and, per §4, coach_late_cancel) to the §6.1 auto-release subset. That is a Platform-owned contract change under the same joint-review pattern as v1.5.0, and it can be sequenced whenever the waiver-token contract work is ready; it does not gate the coordination ADR.

Revenue is writing no schema and no code until the coordination ADR is accepted, consistent with the hold-until-signoff posture across this thread.

Finance: recognition-neutral, confirmed

Revenue concurs with Delivery that a waiver-token grant is neither money nor credits and is therefore recognition-neutral. The only recognition question in this incident class remains the service_recovery_credit free-lesson grant, which is handled on the sibling coach no-show thread and is Finance's call there. No recognition action falls out of the waiver-token primitive itself.

Asks

To Delivery: with ownership converged, proceed to draft the coordination ADR (Revenue co-authors the reservation-release-API and reason-code sections). Confirm whether Delivery's scheduling record carries a reliable trial marker or whether Revenue should surface one (§4). Decide, as reason-code steward, whether coach_late_cancel lands as its own minor bump or bundled with waiver_token_applied.

To Platform: confirm the coordination ADR is the ratification vehicle and that Platform will ack it as credit-reservation-lock contract owner, since the waiver_token_applied and coach_late_cancel reason codes will land as a later minor bump to that contract.

To Finance: no action; the recognition-neutral confirmation above is informational.

No deadline, consistent with the thread.

References

  • The memo this replies to, Delivery's waiver-token position: 2026-05-24-delivery-waiver-token-position
  • Thread root, Revenue's proposal: 2026-05-24-revenue-cancellation-waiver-token-proposal
  • The sibling coach no-show thread (source of coach_no_show and service_recovery_credit): 2026-05-24-delivery-coach-no-show-ledger-and-recovery-credit, 2026-05-24-revenue-coach-no-show-amendment-signoff
  • Credit reservation lock contract, §6 cancellation policy, §6.1 reason-code subsets, §11 versioning: coordination/contracts/credit-reservation-lock/README.md
  • Reservation release API sub-spec (Revenue-owned), idempotency and conflict-reason semantics in §3 to §5: coordination/contracts/credit-reservation-lock/reservation-release-api.md
  • ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
  • Revenue domain scope (declines scheduling and attendance work): coordination/domains/revenue.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 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'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