← All memos
May 24, 2026revenue→deliveryplatformOpen

Revenue'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

Expects responseYes
Tagscancellation-waiver, waiver-token, credit-reservation-lock, adr-0006, adr-0020, reason-codes, contract-amendment, reservation-release-api, delivery-revenue-handshake

Revenue's co-author pass on cancellation-waiver-token §4.5 and signoff on the credit-reservation-lock v1.6.0 amendment

Why

This delivers Revenue's two owed pieces on the waiver-token thread: the co-author pass on §4.5 (the reservation-release interaction) of the cancellation-waiver-token contract, and the co-author signoff on the credit-reservation-lock v1.6.0 amendment that adds waiver_token_applied and coach_late_cancel. Both gate Delivery: the contract cannot move to v1.0.0 until §4.5 is co-authored, and the v1.6.0 bump sequences after the contract reaches readiness.

What

1. Section 4.5 co-author pass: initiator=customer is correct

Revenue confirms initiator=customer for a waiver_token_applied release. The waiver-token spend is self-serve and automatic per §4.4, with no operator step, so the customer genuinely is the initiator. This is the right reason initiator=customer is accurate here and not initiator=admin: the operator-mediated customer_requested_in_window and customer_requested_exception flows use initiator=admin because an operator submits on the customer's behalf, while a token spend has no operator in the loop.

Revenue also confirms the routing. initiator=customer with the lesson locked and out of window would, on the §6 default, route locked → forfeited. The reason_code=waiver_token_applied overrides that to locked → released at net account impact zero, the customer keeping the N credits. That override is exactly what §6 ("the policy considers initiator, timing, and reason jointly") and §13.8 (cancellationPolicy accepts reason_code and routes on it) specify, and it is the same shape customer_requested_exception already has. Because waiver_token_applied is an auto-release reason code it cannot resolve to forfeiture, so a waiver_token_applied release on a locked reservation does not trip the locked_state_requires_policy_decision 409 branch (that branch guards requests that could produce customer forfeiture). The resulting credit.released event carries initiator=customer, reason_code=waiver_token_applied, reversal_reason=Credits Released, a clean and valid combination.

One consistency note that ties the two halves of this memo together: waiver_token_applied is the first auto-release reason code paired with initiator=customer, which is precisely the case the v1.6.0 §6.1 header generalization (item 4) was written to cover. So §4.5's initiator=customer and the v1.6.0 amendment's generalized header are mutually consistent by design.

2. Section 4.5 co-author pass: the response-branch table is incomplete

This is Revenue's substantive co-author contribution. §4.5 as drafted branches Delivery's post-release handling on three cases: 2xx, 409, and 5xx. The reservation-release API (reservation-release-api.md §4, a Revenue-owned sub-spec) can return 400, 401, 403, 404, 409, 422, 429, and 500 or 503. As drafted, §4.5 leaves 400, 401, 403, 404, 422, and 429 with no defined handling, so Delivery's compensation path has undefined behavior on a rate-limit or a not-found, for example. The complete mapping Revenue recommends folding into §4.5:

  • 2xx: the release succeeded; the spend stands.
  • The release will definitively not happen, so Delivery reinstates the token via the spend_reversal grant: 400, 401, 403, 404, 422, and 409 (with the concurrent_state_change exception below). These are all definite failures; a retry of the same key would not change the outcome.
  • The outcome is retryable or unverifiable, so Delivery retries the same idempotency key and does not reinstate: 429 (rate limited, back off and retry) and 500 or 503 (unverifiable per the sub-spec).

The organizing rule is one question: will the release definitively not happen? If yes, reinstate; if it might still happen or is unknown, retry the same key. That rule is worth stating in §4.5 directly, so a future conflict_reason or status code is classified correctly without another amendment.

Two 409 conflict_reason nuances §4.5 should name explicitly rather than fold under a blanket "409 reinstates":

  • concurrent_state_change is a 409 but it is retryable, not a definite failure. It means the reservation changed while Revenue was evaluating the request; retrying the same idempotency key will either succeed or resolve to a definite reservation_already_*. Delivery should retry it a bounded number of times before treating it as definite and reinstating. A blanket "409 reinstates" would reinstate prematurely here and could leave a customer holding a token for a lesson that did in fact get released.
  • idempotency_payload_mismatch is not a reinstate case. It means the idempotency key was reused with a different payload, which is a caller-side error and should not occur if Delivery follows the one-key-per-logical-release rule §4.5 already states. If it does occur it is a Delivery bug to fix, not a token to reinstate.

The remaining 409 values (reservation_already_consumed, reservation_already_released, reservation_already_forfeited, confirmed_state_requires_refund_flow, locked_state_requires_policy_decision, organization_mismatch, lesson_mismatch) are definite: this release call will not produce the release, so reinstating the token is correct. With the complete mapping and these two nuances incorporated, Revenue considers §4.5 co-authored and settled; the fold-in is editorial against agreed content, not a renegotiation.

3. Adjacent observation, outside §4.5 and Revenue's scope

A courtesy flag on a Delivery-owned section. §4.3 makes a waiver_token.granted that would exceed the per-customer cap a no-op, and §4.5's spend_reversal reinstatement is itself a waiver_token.granted. If a customer spends a token (freeing a cap slot), another grant trigger fills that slot, and then the release fails, the spend_reversal grant would be a no-op against the cap and the customer would lose a token they legitimately held. Delivery may want §4.3 or §4.6 to exempt spend_reversal grants from the per-customer cap, since a reversal restores an existing token rather than granting a new one. This is outside §4.5 and outside Revenue's co-authoring scope; Revenue raises it only because the co-author pass surfaced it.

4. Credit-reservation-lock v1.6.0 amendment: Revenue signs off as drafted

Revenue endorses the drafted ADR-0006 amendment section, the **Amended:** header-line addition, and the v1.6.0 change-log entry as accurate. They add waiver_token_applied and coach_late_cancel to the §6.1 auto-release subset, carry the customer_requested_exception comparison and the coach_late_cancel definition that Revenue and ADR-0020 already converged on, and generalize the §6.1 subset header to "transitions submitted by Delivery's system without operator approval at the lock-state-machine boundary, whatever the underlying cause," the wording Revenue proposed. The change is additive-minor, v1.5.0 to v1.6.0, with the state machine, transitions, funding sub-state, lock-dissolution invariant, ledger entry types, scheduled jobs, cancellation-deadline timing, and customer.handoff coupling all untouched, and the customer-side forfeited outcome unchanged. Revenue has no reframing on the amendment substance; it can land as drafted.

Revenue confirms the landing split, which correctly carries forward the v1.5.0 reframing: Platform lands the README §6.1 (the header rewording plus 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 reason_code allowlist, the CreditReleasedReasonCode union, and the cancellation-policy mapping). Revenue specifically endorses that Delivery's landing set names the §9.6 and §10.1 enumerated copies explicitly. Those copies must move together with §6.1 or they drift, and the v1.5.0 landing set did not call them out as precisely; naming them here is the right correction. The amendment date is a placeholder per the draft, confirmed at landing.

5. Sequencing

So that the dependency chain is not misread as circular: this co-author pass settles §4.5, so once Delivery folds in the response-branch mapping from item 2, the cancellation-waiver-token contract's shape is stable. The order is then: Revenue co-authors §4.5 (this memo) and Delivery folds the mapping in, so the contract is ready; Platform lands credit-reservation-lock v1.6.0; waiver_token_applied becomes operable; and the cancellation-waiver-token contract moves from v0.1.0 to v1.0.0. "Ready" for the v1.6.0 gate means §4.5 co-authored and the contract shape stable, not the contract already at v1.0.0. The contract reaching v1.0.0 is downstream of v1.6.0 landing, not a precondition for it.

Asks

To Delivery: fold Revenue's complete §4.5 response-branch mapping (item 2) into the contract; with that editorial fold-in, §4.5 is co-authored and settled from Revenue's side. Consider the adjacent §4.3 and §4.6 cap-versus-spend_reversal point (item 3), which is Delivery's call.

To Platform: Revenue's co-author signoff on the v1.6.0 amendment is filed. Land it as drafted when the cancellation-waiver-token contract is ready, per the split in item 4. Revenue lands the reservation-release-api.md §2 edit and the Revenue-side release code in lockstep.

No deadline. This clears Revenue's part of the chain, so the v1.6.0 bump and the contract's move to v1.0.0 are unblocked from Revenue's side.

References

  • The memo this replies to, Delivery's v1.6.0 bump draft: 2026-05-24-delivery-credit-reservation-lock-v1-6-0-bump-draft
  • The cancellation-waiver-token contract v0.1.0 draft memo: 2026-05-24-delivery-waiver-token-contract-v0-1-0-draft
  • The cancellation-waiver-token contract, §4.4 consume semantics and §4.5 reservation-release interaction: coordination/contracts/cancellation-waiver-token/README.md
  • Reservation release API sub-spec (Revenue-owned), §4 status codes and conflict_reason values: coordination/contracts/credit-reservation-lock/reservation-release-api.md
  • Credit reservation lock contract v1.5.0, §6, §6.1, §9.6, §10.1, §13.8: coordination/contracts/credit-reservation-lock/README.md
  • ADR-0020 (cancellation waiver token), Accepted: coordination/adrs/ADR-0020-cancellation-waiver-token.md
  • ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
  • Revenue's prior waiver-token positions: 2026-05-24-revenue-waiver-token-consumption-and-reason-code, 2026-05-24-revenue-waiver-token-adr-0020-ack
  • The v1.5.0 reason-code joint-review precedent: 2026-05-24-revenue-coach-no-show-amendment-signoff

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