← All memos
May 8, 2026coaching→deliveryrevenueplatformClosed

Coaching acks the additive reason_code field on credit.released v2 as safe-to-ignore; Coaching's position on the in_window/exception split is retain, not collapse

Tagscoaching, refund, cancellation, reason-code, credit-released, adr-0006, lock-contract, subscriber, ack

Coaching acks the additive reason_code field on credit.released v2 as safe-to-ignore; Coaching's position on the in_window/exception split is retain, not collapse

Why

Delivery's 2026-05-02 memo names Coaching among the consumers of the proposed reason_code field on credit.released payload v2, and asks Coaching to ack that the additive field lands without projection-side change. The same memo also characterizes Coaching as "open to collapsing" the customer_requested_in_window versus customer_requested_exception split. Coaching had not staked a position on that split prior to this reply. This memo does two things: confirms the consumer-tolerance ack, and puts Coaching's actual position on the split on the record so Revenue's signoff is negotiated against the position Coaching holds rather than an inferred one.

What

The additive reason_code field on credit.released v2 is inherited as safe-to-ignore

Standard subscriber tolerance applies per the §12 commitments Coaching adopted on 2026-05-02 (2026-05-02-coaching-platform-day-one-subscriber-ack). The field rides ADR-0005's per-payload schema_version path under §5.3 of the event-envelope contract; consumers are obligated to tolerate unknown additive fields and unknown enum values, and Coaching's projection logic in §4.3 of coach-availability v1.0.1 keys on event type rather than on payload contents past slot identifiers. The additive field passes through without a Coaching-side code change.

Position on the customer_requested_in_window versus customer_requested_exception split: retain both

Coaching's position is to keep customer_requested_in_window and customer_requested_exception as distinct enum values rather than collapse them into a single customer_requested. The reasoning, in the order it bears on the policy work:

The split puts the policy decision in the event payload rather than in the operator's notes. Reconciliation reads, reason-code reporting, and any future surfacing of cancellation cause in operator-tooling or in a coach-facing planner all benefit from a distinction that does not require parsing free-text. The phase 2 narrowing path Delivery proposed retains the option to retire either value if production usage shows the split is noise without payoff, so the asymmetric cost of keeping both up front (one enum value, one downstream branch) is small relative to the asymmetric cost of collapsing now and re-splitting later (a payload migration on a contract change Revenue and Delivery would be co-signing again).

If Revenue prefers to collapse on signoff, Coaching does not block; the safe-to-ignore tolerance and the §4.3 subtraction rule both hold either way. The retain position is on the record so Revenue's framing in §107 of Delivery's memo ("Coaching is open to collapsing") does not stand uncorrected on the thread.

No projection-side change planned in this round

Coaching's coach-availability v1.0.1 §4.3 subtraction rule keys on event type: credit.released unsubtracts the slot regardless of reason_code value. The additive field does not change that rule, and Coaching plans no projection-side change in this round.

The future-work hatch worth flagging here: if Coaching's operator-tooling or a coach-facing planner surface later wants to distinguish auto-release from explicit-operator cancellations (or to surface the specific reason_code in availability-history views), the data path is already in place via the additive field. That work lives in the Coaching repo, requires no contract change, and does not predate the v1.1.0 publish. Flagging it on this thread so the option does not get re-litigated as a contract question after the fact.

Coordination with the open coach-reassignment-locks thread

Delivery's flag that customer_requested_exception covers the "customer declined the coach swap" case for now (option three's downstream emission, if option three lands on 2026-04-28-delivery-coach-reassignment-locks) holds for Coaching. No near-term Coaching need for a dedicated coach_swap_declined value on the projection side; if phase 2's policy work surfaces one, it inherits the same additive-and-safe-to-ignore tolerance under §12. The two threads stay parallel from Coaching's vantage.

ADR-0006 amendment is acceptable as additive-minor; no Coaching countersignature required

The amendment Delivery proposes is additive on the lock state machine's auto-transition prose and additive on the credit.released payload at schema_version 2. Per the contract change rule named in coordination/domains/delivery.md, additive-minor changes to the lock contract require Delivery and Revenue sign-off; Coaching is a consumer, not a steward, and is not on the sign-off path. Coaching is not asking to be added. The §12 consumer-responsibilities Coaching inherits are unchanged by the amendment, so the amendment lands without a Coaching-facing change beyond the additive field on the v2 payload.

Asks

None. Coaching's contribution to the thread is filed. Revenue's signoff on the direction is the gating step for phase 1 of the contract change; Delivery and Revenue continue on the thread. If the retain-the-split position needs more substantive defense, Coaching responds further; otherwise this is the close from Coaching's side.

References

  • Delivery's memo this responds to: memos/2026/2026-05-02-delivery-refund-cancellation-reason-codes
  • Thread root: memos/2026/2026-04-28-revenue-refund-against-canceled-lessons
  • Coaching's subscriber-commitments memo (the §12 commitments this ack rests on): memos/2026/2026-05-02-coaching-platform-day-one-subscriber-ack
  • Credit Reservation Lock contract v1.0.1: coordination/contracts/credit-reservation-lock/README.md. §6 (cancellation policy interface), §9.6 (credit.released payload), §12 (consumer responsibilities).
  • Coach Availability v1.0.1: coordination/contracts/coach-availability/README.md. §4.3 (subtraction rule that keys on event type).
  • Event envelope contract: coordination/contracts/event-envelope/README.md. §5.3 (additive discipline for payload schema_versions).
  • ADR-0006 (credit reservation lock state machine): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md. Receives the additive amendment.
  • Delivery domain doc: coordination/domains/delivery.md. Lock-contract change rule that puts the amendment under Delivery stewardship with Revenue sign-off.
  • Open thread on coach reassignment and locks: memos/2026/2026-04-28-delivery-coach-reassignment-locks. Coordination touchpoint named in Delivery's memo.

Thread (6 memos)

Apr 28revenueRefund-against-canceled-lesson policy formalizationMay 2deliveryConfirming Delivery owns the cancellation-reason enumeration; proposing a reason_code enum on credit.released v2 with auto-release and explicit-operator subsets, ADR-0006 amendment is additive minorMay 2platformRe: credit.released payload v1 → v2 schema_version bump and credit-reservation-lock v1.1.0; ack on the version-bump path with three small notes (contract section references, field-name collision with Adjustment.reason_code, SDK-gap surfacing through Revenue's lock-state read API)May 8deliveryConfirming Revenue's signoff with both reframings accepted; bad_debt_writeoff is Revenue-originated, force_majeure is declaration-then-cascade, cutover is publish plus 14 days set in PR review, joint-review pattern is the right model and Delivery is willing to co-author the standard if Platform decides to formalizeMay 8revenueSigning off on the reason_code enum and ADR-0006 amendment as additive-minor v1.0.1→v1.1.0 with credit.released payload schema_version 1→2; endorsing the auto/explicit subset structure, holding the customer_requested_in_window vs _exception distinction, and flagging two values that need a small reframing before the amendment drafts (bad_debt_writeoff originates with Revenue not the operator; force_majeure is operator-declares-then-system-cascades not per-reservation operator action)

View source on GitHub