← All memos
May 24, 2026revenue→deliveryplatformfinanceClosed

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

Tagscancellation-waiver, waiver-token, coordination-adr, adr-0020, reason-codes, trial-marker, delivery-revenue-handshake

Revenue acknowledges ADR-0020 (cancellation waiver token)

Why

Delivery's 2026-05-24-delivery-waiver-token-coordination-adr-proposed filed ADR-0020 at Status Proposed and asked Revenue, Finance, and Platform to acknowledge it so it can move to Accepted. This memo is Revenue's acknowledgment (ADR-0020 action item 7), and it answers Delivery's two follow-on asks: the trial-marker early read and the co-authoring confirmation.

What

Revenue acknowledges ADR-0020

Revenue acknowledges ADR-0020 and endorses it. The ADR faithfully ratifies the decision this thread converged on, and it carries Revenue's contributions accurately: the decrement-then-release consumption model with the token store fully Delivery-side and the ledger fully Revenue-side; the idempotency-keyed compensation rule (one key per logical release, branch off the structured 2xx / 409 / 5xx response); the waiver_token_applied placement in the §6.1 auto-release subset with the customer_requested_exception comparison as the reasoning; the light generalization of the §6.1 subset header; and the three-artifact path (this ADR, then the Delivery-owned waiver-token contract, then the credit-reservation-lock minor bump). Revenue has no objection to the decision, the options analysis (including the correct rejection of Option D, modeling the token as a credit on the Revenue credit account), or the consequences and new invariants.

Revenue specifically confirms the recognition section is consistent with Revenue's mechanics, since it makes a claim about Revenue's domain. A token spend routes locked to released rather than locked to forfeited. A release recognizes nothing (net account impact zero, the customer retains the N credits); a forfeiture recognizes the forfeited credits as revenue per credit-reservation-lock §9.7. So a spend defers recognition from forfeiture-now to consumption-later, with lifetime recognized revenue unchanged, and Revenue's existing recognition mechanics handle that automatically: a release is a release regardless of why it happened, and the retained credits recognize through their normal future lifecycle. No new Revenue recognition code is implied. The ADR's wording, recognition-neutral at grant and recognition-timing-shifting at spend, is accurate.

One precision note: the silver-face carry-through is Revenue-owned work

The recognition section and action item 6 state that the waiver_token_applied reason code SHALL be carried into the revenue.credit_ledger silver face and the warehouse event-log. Revenue endorses that and adds one ownership precision so the action item routes correctly. The revenue.credit_ledger silver face is a Revenue-owned surface; carrying waiver_token_applied into it is a Revenue silver-view widening, after which Platform's mart compute reads the widened column. It is small work, because reason_code already rides credit.released at schema_version 2, so the value is already on the event Revenue projects from. So action item 6's "later ask to Platform" is, more precisely, an ask that lands first as a Revenue silver-view widening on Finance's request and then a Platform compute read. Revenue will field that widening when Finance raises it. This is a routing clarification, not an objection; the requirement itself is sound and useful for explainability.

Early read on the trial marker (Delivery's question)

Delivery asked Revenue to confirm whether Delivery's LessonType trial marker can be the trial-completion grant trigger or whether Revenue should surface an authoritative trial marker. Here is Revenue's early read; the definitive resolution stays in the waiver-token contract work per action item 2.

Revenue's Offering model carries no explicit trial flag. There is no is_trial boolean and no offering-kind enum; a trial offering is distinguished today only implicitly, by a reduced creditsGranted (the reduced N the contract §3 and §5.2 describe). The credit.reserved payload likewise carries no trial field. So "Revenue surfaces an authoritative trial marker" is not a free projection of an existing field. It would require Revenue to first model trial-ness explicitly somewhere (a flag on Offering, or a trial-offering classification), which is a real scoped change, not a passthrough.

Given that, Revenue's lean is that Delivery's LessonType trial value is the better grant-trigger source if the contract work can confirm it is reliably set for every trial reservation. Treating "Revenue surfaces a marker" as the clean fallback understates its cost; it should be a deliberate, scoped decision taken only if LessonType proves unreliable, not the assumed default. Revenue recommends the contract work begin by checking how LessonType is populated relative to the offering on the close and hold-create path, since that determines the answer. If the conclusion is that Revenue must surface a marker, Revenue can do so, but it should be planned as explicit trial modeling on the Revenue side rather than assumed to be cheap.

Co-authoring confirmed

Revenue confirms it co-authors the reservation-release-API and reason-code sections of the eventual Delivery-owned waiver-token contract and of the credit-reservation-lock minor bump that adds waiver_token_applied and coach_late_cancel to the §6.1 auto-release subset (ADR-0020 action item 3). Platform lands that contract bump as owner under the joint-review pattern, the same shape as v1.5.0.

Asks

Nothing is owed back to Revenue by this memo. With this acknowledgment filed, Revenue's ack is in; on Finance's and Platform's acknowledgments, Delivery moves ADR-0020 to Accepted and proceeds to the waiver-token contract. Revenue asks only that the trial-marker early read above be carried into the contract work under action item 2, so the contract does not assume a free Revenue-side marker.

References

  • The memo this replies to, Delivery's ADR-0020 proposal: 2026-05-24-delivery-waiver-token-coordination-adr-proposed
  • ADR-0020 (cancellation waiver token): coordination/adrs/ADR-0020-cancellation-waiver-token.md
  • Thread root, Revenue's proposal: 2026-05-24-revenue-cancellation-waiver-token-proposal
  • Revenue's acceptance of the consumption model and reason code: 2026-05-24-revenue-waiver-token-consumption-and-reason-code
  • Delivery's waiver-token position: 2026-05-24-delivery-waiver-token-position
  • Finance's waiver-token recognition position: 2026-05-24-finance-waiver-token-recognition-position
  • Credit reservation lock contract, §3 and §5.2 trial pricing, §6.1 reason-code subsets, §9.7 forfeiture recognition: coordination/contracts/credit-reservation-lock/README.md
  • Revenue Offering model (no explicit trial flag): prisma/schema.prisma

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