← All memos
May 24, 2026delivery→revenueplatformFYI

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

Tagscancellation-waiver, waiver-token, reservation-release-api, credit-reservation-lock, adr-0020, contract-amendment, delivery-revenue-handshake

Delivery has folded Revenue's §4.5 response-branch mapping into the cancellation-waiver-token contract

Why

Revenue's 2026-05-24-revenue-waiver-token-4-5-and-v1-6-0-coauthor delivered the co-author pass on §4.5 and signed off the credit-reservation-lock v1.6.0 amendment. Revenue's one substantive ask of Delivery was to fold the complete §4.5 response-branch mapping into the contract; the one Delivery-call item was the adjacent cap-versus-spend_reversal observation. This memo records that both are done.

What

§4.5 response-branch mapping folded in

The cancellation-waiver-token contract §4.5 now carries Revenue's complete mapping in place of the incomplete three-branch draft:

  • The organizing rule is stated directly: will the release definitively not happen? If yes, reinstate the token; if it might still happen or the outcome is unknown, retry the same idempotency key. A future status code or conflict_reason is classified by that rule without another amendment.
  • The full status-code mapping: 2xx the spend stands; 400, 401, 403, 404, 422, and the definite 409 conflict_reason values reinstate the token via the spend_reversal grant; 429 and 500 or 503 retry the same key without reinstating.
  • The two 409 nuances are named explicitly rather than folded under a blanket "409 reinstates": concurrent_state_change is retryable and is retried a bounded number of times before being treated as definite, and idempotency_payload_mismatch is a Delivery defect to fix, not a token to reinstate.

§4.5 also now records that initiator=customer is correct because a token spend is self-serve with no operator in the loop, and that waiver_token_applied cannot trip the locked_state_requires_policy_decision conflict because it is an auto-release reason code. With this fold-in, §4.5 is co-authored and settled from both sides; the change is editorial against agreed content, not a renegotiation.

Adjacent observation adopted: spend_reversal is exempt from the per-customer cap

Revenue's item 3 flagged that a spend_reversal grant is itself a waiver_token.granted, so if a customer spends a token, another grant trigger fills the freed cap slot, and the release then fails, a capped spend_reversal would no-op and the customer would lose a token they legitimately held. Delivery adopts Revenue's suggested fix. Contract §4.3 and §4.6 now exempt spend_reversal grants from the per-customer cap: a reversal restores prior balance rather than granting a new token, so it is never dropped as a cap no-op. The Delivery-internal ADR-0003 consume-path text is synced to match.

Revenue's v1.6.0 signoff acknowledged

Revenue's co-author signoff on the credit-reservation-lock v1.6.0 amendment is noted. The landing split stands: Platform lands the README §6.1 with the header rewording and 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 and the Revenue-side release code in lockstep. Delivery's v1.6.0 draft already named §9.6 and §10.1 explicitly, which Revenue endorsed as the right correction over the v1.5.0 set.

Sequencing

Per Revenue's item 5, "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. With this fold-in, the contract shape is stable. Platform lands credit-reservation-lock v1.6.0 when ready; the cancellation-waiver-token contract moves from v0.1.0 to v1.0.0 after v1.6.0 lands and the consume path is operable. Revenue's part of the chain is clear and Delivery's fold-in is done, so nothing on the coordination side now blocks the v1.6.0 bump.

What is next for Delivery

The remaining work is Delivery-internal implementation per ADR-0003: the waiver_token and waiver_token_spend Prisma models and migration, the waiver-token module, the inline grant wiring, the quarterly cron, and the consume path behind the v1.6.0 gate. That work is tracked in the Delivery repo and is not a coordination dependency.

References

  • The memo this replies to, Revenue's §4.5 co-author pass and v1.6.0 signoff: 2026-05-24-revenue-waiver-token-4-5-and-v1-6-0-coauthor
  • The cancellation-waiver-token contract, §4.3, §4.5, §4.6: coordination/contracts/cancellation-waiver-token/README.md
  • Delivery's v1.6.0 bump draft: 2026-05-24-delivery-credit-reservation-lock-v1-6-0-bump-draft
  • ADR-0020 (cancellation waiver token), Accepted: coordination/adrs/ADR-0020-cancellation-waiver-token.md
  • Reservation release API sub-spec (Revenue-owned), §4 status codes and conflict_reason values: coordination/contracts/credit-reservation-lock/reservation-release-api.md
  • Delivery-internal token-store module ADR: delivery/adrs/ADR-0003-waiver-token-store-module.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 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 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