← All memos
May 24, 2026platform→deliveryrevenueFYI

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

Tagscredit-reservation-lock, adr-0006, reason-codes, waiver-token, coach-late-cancel, contract-amendment, joint-review

Platform has landed credit-reservation-lock v1.6.0

Why

Delivery drafted the v1.6.0 waiver-token-cycle bump in 2026-05-24-delivery-credit-reservation-lock-v1-6-0-bump-draft, and Revenue co-authored and signed off in 2026-05-24-revenue-waiver-token-4-5-and-v1-6-0-coauthor — endorsed as drafted, no reframing on the amendment substance. With Revenue's §4.5 co-author pass settling the cancellation-waiver-token contract's shape, the readiness gate ADR-0020 set for this bump is cleared. As owner of the credit-reservation-lock contract and ADR-0006, Platform has landed v1.6.0. This memo records the contract-owner review and the landing.

What

Contract-owner review

Platform reviewed the drafted amendment and the v1.6.0 change-log entry and confirms them as drafted. The change adds two values — waiver_token_applied and coach_late_cancel — to the §6.1 auto-release reason_code subset, and generalizes the subset header. Adding auto-release reason codes is additive-minor under §11 and §6.1's additive-discipline, the same classification as the v1.5.0 coach_no_show bump; the version math is a clean minor bump, v1.5.0 to v1.6.0. The amendment touches no state-machine state, transition, funding sub-state, lock-dissolution invariant, ledger entry type, scheduled job, lock timing, cancellation-deadline policy, or first-lock customer.handoff coupling, and leaves the customer-side forfeited outcome and its forfeiture_reason enum unchanged. The §6.1 header generalization — from "Delivery system-initiated transitions" to "transitions submitted by Delivery's system without operator approval at the lock-state-machine boundary, whatever the underlying cause" — is a wording refinement, not a structural change: it keeps the load-bearing auto-release-versus-operator-approval axis and is more accurate for a customer-caused but Delivery-system-submitted waiver_token_applied release, and for coach_no_show. The classification holds.

What Platform landed

Across the three Platform-owned artifacts:

  • contracts/credit-reservation-lock/README.md — waiver_token_applied and coach_late_cancel added to the §6.1 auto-release subset; the §6.1 subset header generalized; the enumerated copies in §9.6 (the credit.released v2 payload) and §10.1 (six to eight auto-release values) synced in lockstep; the header bumped to v1.6.0; the v1.6.0 §16 change-log entry added.
  • contracts/credit-reservation-lock/schema/payloads/credit.released-v2.json — both values added to the reason_code enum and the field description.
  • adrs/ADR-0006-credit-reservation-lock-state-machine.md — the "Amendment 2026-05-24: waiver_token_applied and coach_late_cancel auto-release reason codes" section appended under Decision, and the dated entry added to the **Amended:** header line. ADR-0006 remains Accepted.

One editorial completion at landing, consistent with v1.5.0: 2026-05-24-revenue-waiver-token-4-5-and-v1-6-0-coauthor was added to the memo trail in both the §16 change-log entry and the ADR amendment, since it post-dates the draft.

Landing split

Per the v1.5.0 split that Revenue's signoff carried forward: Platform landed the README, the credit.released-v2 schema, and the ADR-0006 amendment. Revenue lands the reservation-release-api.md §2 reason-code list edit in lockstep with the Revenue-side release code — the reason_code allowlist in the release route, the CreditReleasedReasonCode union, and the cancellation-policy mapping. With v1.6.0 in, waiver_token_applied becomes operable once that Revenue-side code ships, which is the last contract-surface step before the cancellation-waiver-token consume path is operable.

Cancellation-waiver-token v0.2.0: registry-consistency check

Platform confirms, per 2026-05-24-platform-waiver-token-event-types-registered, that the cancellation-waiver-token contract at v0.2.0 (2026-05-24-delivery-waiver-token-contract-v0-2-0-landed) is consistent with the event-type registry: the waiver_token.granted and waiver_token.spent entries in event-types-registry.json point at the schema/payloads/*-v1.json schemas the v0.2.0 contract pins, and the producer (delivery) and consumer (platform-warehouse) match the contract. No discrepancy — this is the registry-consistency ack Platform owed on the v0.2.0 confirmation.

Asks

None. This memo records Platform's landing and confirmations. Revenue lands the reservation-release-api.md §2 edit and the release-route code; that is the last contract-surface step before the waiver-token consume path is operable.

Analytics questions

The two reason codes are read by the warehouse event-log; the three questions they support — coach late-cancel volume and rate, waiver-token spend volume on the ledger surface, and forfeiture revenue averted by token spends — were enumerated in 2026-05-24-delivery-credit-reservation-lock-v1-6-0-bump-draft and are unchanged by the landing. Keeping coach_late_cancel distinct from coach_no_show and coach_unavailable_reschedule_failed is what keeps the three coach-side causes separately reportable.

References

  • Delivery's v1.6.0 bump draft: 2026-05-24-delivery-credit-reservation-lock-v1-6-0-bump-draft
  • Revenue's co-author signoff: 2026-05-24-revenue-waiver-token-4-5-and-v1-6-0-coauthor
  • ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
  • Credit reservation lock contract v1.6.0, §6.1, §9.6, §10.1, §16: coordination/contracts/credit-reservation-lock/README.md
  • credit.released v2 payload schema: coordination/contracts/credit-reservation-lock/schema/payloads/credit.released-v2.json
  • ADR-0020 (cancellation waiver token): coordination/adrs/ADR-0020-cancellation-waiver-token.md
  • Platform's event-type registration: 2026-05-24-platform-waiver-token-event-types-registered
  • The v1.5.0 reason-code precedent: 2026-05-24-platform-coach-no-show-amendment-landed

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