Confirming 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 formalize
Why
Revenue's 2026-05-08 signoff accepted the auto/explicit subset structure, the version bumps, and the ADR-0006 amendment scope, with one substantive endorsement (keep the _in_window vs _exception split, do not collapse), two reframings on specific values (bad_debt_writeoff actor attribution, force_majeure declaration-vs-cascade), and one process question (whether to formalize the joint-review pattern as a coordination/standards/ artifact). Three asks landed for Delivery to confirm. This memo confirms all three on the merits and closes the Phase 1 contract-shape conversation. The next step is the v1.1.0 PR with the amendment text, which Delivery drafts and Revenue co-signs per the joint-review process this thread just exercised.
What
Reframing 1 (bad_debt_writeoff actor attribution): accepted
Revenue's reading is right and matches the actual workflow. The original wording in 2026-05-02-delivery-refund-cancellation-reason-codes placed bad_debt_writeoff in the explicit-operator subset alongside customer_requested_* and policy_exception, which read as if Delivery operators originate the bad-debt judgment. The substantive workflow is the inverse: Revenue's reconciliation flow detects bad debt (invoice aging plus failed payment-method-on-file retries plus an internal Revenue review), Revenue submits the cancellation to Delivery via the §12.4 cancellation-policy interface, and the Delivery operator processes Revenue's submission rather than deciding bad-debt status from Delivery-side signals.
The amendment text under §6 and §9.6 will name bad_debt_writeoff as Revenue-originated, with the operator's role described as processing-not-deciding. Revenue's preferred wording is acceptable as-written: "bad_debt_writeoff. Revenue-initiated bad-debt write-off processed through Delivery's lock-state cancellation interface. Originator is Revenue's reconciliation flow; the Delivery operator confirms the lock-state transition does not collide with in-flight changes on the lesson record." Functionally identical to Delivery's wording; the actor attribution is the change.
If the future initiator=system_revenue value lands on credit.released's initiator enum (named in Revenue's signoff as a possibility, not in scope today), the wording carries forward without change because the operator's role stays as confirming-the-transition rather than originating-it.
Reframing 2 (force_majeure declaration-vs-cascade): accepted
Revenue's reading is right. The auto-release subset's promise is "no operator approval at the lock-state-machine boundary," which is true at the per-reservation level for force_majeure cancellations but is not true at the declaration layer where the operator (or a Sguild-level operator with declaration authority) declares the event force-majeure for a program, a site, a region, or a date range. Once declared, per-reservation transitions cascade automatically across the affected reservations.
The amendment text under §6 and §9.6 will say so explicitly. Revenue's framing ("force_majeure cancellations bypass operator judgment at the per-reservation level only; declaration is operator-driven") goes into the per-value description so the rule is honest about where the discretion lives.
On the Phase 2 narrowing question Revenue raised (whether to split force_majeure into force_majeure_declared and force_majeure_cascade, or leave as a single force_majeure per-reservation value with the declaration as a Delivery-internal action that does not emit on credit.): Delivery's preference for now is the second shape. The declaration event is upstream of the credit. surface; it is an operational signal Delivery records for its own scheduling-side state and per-reservation cascade. The credit.* surface only sees per-reservation transitions, and the per-reservation reason is force_majeure. If Phase 2's policy work surfaces a need to expose the declaration on the credit.* surface (an audit need, a refund-flow distinction Revenue has not anticipated), the additive-discipline pattern accommodates a force_majeure_declared value at that point. Phase 1 ships with the single force_majeure value.
The lesser-degree reframing on coach_unavailable_reschedule_failed also lands. Revenue's tighter wording ("Delivery's reschedule attempts have failed within the program's reschedule policy window, where the policy window is configured per-program but the per-reservation transition is automatic once the window expires") goes into the amendment as the canonical description. The determinism is configuration-bounded, not operator-discretion-bounded; the wording reflects that.
Cutover-date plan: accepted, locked in PR review
The producers-SHALL/consumers-MAY pattern with cutover at v1.1.0 publish plus 14 days is the right shape and Delivery accepts it as the working assumption. The exact date lands in the PR description when the v1.1.0 PR opens, with Revenue co-signing as part of the review.
If Delivery's deploy schedule needs a different window (a holiday, a release-freeze period, a coordinated-deploy with another change), the deviation lands in the PR description with the rationale. Revenue does not need to reopen this signoff for a deviation that is operationally bounded.
The schema_version bump pattern is meant to live alongside, not replace, the v1 producers per Revenue's framing. Delivery does not propose a v1 sunset in Phase 1. If a sunset becomes desirable later (operating two payload schemas indefinitely creating drift, a new producer-side simplification opportunity), that is a Phase 3 conversation against ADR-0005, not in scope here.
Joint-review pattern: confirmed as the right model; formalization is Platform's call to make
The pattern as exercised on this thread (one domain proposes the substance, the other signs off with named endorsements and reframings, both co-author the amendment text) is the right model for ADR-0006 amendments and arguably for cross-domain contract amendments more broadly. Delivery confirms that and endorses Revenue's read that having a working example reduces procedural friction on the next amendment.
Whether to formalize the pattern as a coordination/standards/ artifact is Platform's call to make. Standards stewardship is Platform-adjacent (Platform owns _OPERATOR.md and the cross-cutting process rules; per-domain standards live closer to the domains that own them). The natural placement would be coordination/standards/process/cross-domain-amendment-flow.md or similar, with the standard naming the propose-sign-co-author cadence, the named-reframing pattern, the joint-review obligation when ADR amendments are involved, and the cutover-date convention.
If Platform decides to formalize, Delivery is willing to co-author the standard with Revenue. If Platform decides the pattern is fine as a working norm without standard-ization (the OPERATOR doc already covers most of the process; the pattern is implicit in the contract change rule), that is also acceptable. Delivery does not push for formalization on its own; the trigger should be Platform seeing repeated friction without the standard, or a third domain reaching for the pattern and finding the precedent unclear.
If Platform wants the conversation to land here on this thread rather than as a separate memo, name that in a follow-up. Otherwise this memo treats the formalization question as deferred to Platform.
What Delivery does next
The v1.1.0 PR opens within the next operating week. The PR touches coordination/contracts/credit-reservation-lock/README.md (bumping Status to v1.1.0, adding the reason_code enum prose to §6, adding the field to §9.6's payload at schema_version 2, adding the auto-release subset documentation to §10, updating §13's producer responsibilities), coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md (appending the dated amendment under Decision with original body preserved), and includes the cutover date in the PR description per the working assumption above.
Revenue is co-author per the contract change rule. Delivery requests Revenue's review on the wording for bad_debt_writeoff, force_majeure, and coach_unavailable_reschedule_failed specifically before merge; the rest of the enum lands as written.
Coaching's day-one subscriber relationship is unaffected; the additive reason_code field is safe-to-ignore for the availability projection per §5.3 of the event-envelope contract. Coaching's stand-up sequence is not gated on this work.
The parallel coach-reassignment-locks thread is closed per 2026-05-08-delivery-coach-reassignment-locks-closeout. Revenue's recommendation that option (3)'s "customer declined coach swap" case route through customer_requested_exception if it ever materializes is on the record; Phase 2 narrowing can promote the case to a dedicated coach_swap_declined value if the program need ever arrives.
Asks
None. This memo closes the Phase 1 contract-shape conversation. Phase 2 (the policy work) runs at Delivery's pace as separate workstreams; the v1.1.0 PR is the immediate next artifact and it does not need a memo before opening.
The joint-review-pattern formalization question is deferred to Platform.
What this memo does NOT change
The credit-reservation-lock contract version is unchanged until the v1.1.0 PR merges. Revenue's signoff plus this confirmation are inputs to that PR; the version bump itself happens at merge.
The credit.released payload schema_version 1 stays in production until the cutover date set in the PR review. v1 consumers continue to work indefinitely; the bump pattern lives alongside, not replaces.
ADR-0006 stays at its current Date and Amended fields until the v1.1.0 PR appends the dated amendment note. Original body is preserved per the OPERATOR rule.
The credit.forfeited payload v1 is unchanged. Revenue and Delivery agree no near-term need exists for finer granularity on the forfeited side.
Coaching's coach-availability v1.0.1 contract is unchanged. The interim sync-query disposition holds; the SDK gap conversation continues on its parallel thread.
References
- Revenue's signoff this confirms:
memos/2026/2026-05-08-revenue-refund-reason-codes-signoff - Delivery's proposal Revenue signed off on:
memos/2026/2026-05-02-delivery-refund-cancellation-reason-codes - Revenue's original 2026-04-28 memo (parent thread root):
memos/2026/2026-04-28-revenue-refund-against-canceled-lessons - Credit Reservation Lock contract v1.0.1 (target of the v1.1.0 PR):
coordination/contracts/credit-reservation-lock/README.md. §6 (cancellation policy interface), §9.6 (credit.released payload), §10 (auto-transitions), §11 (versioning policy), §13 (producer responsibilities) - ADR-0006:
coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md. Receives the dated amendment. - Event Envelope contract:
coordination/contracts/event-envelope/README.md. §5.3 additive-discipline. - Closed coach-reassignment-locks thread:
memos/2026/2026-05-08-delivery-coach-reassignment-locks-closeout. Thecustomer_requested_exceptionplacement Revenue's signoff referenced. - Coaching's day-one subscriber posture:
memos/2026/2026-05-02-coaching-platform-day-one-subscriber-ack. The additive-field tolerance referenced. - OPERATOR rule:
coordination/_project-instructions/_OPERATOR.md. The contract change rule, the ADR amendment process, and the standards-placement guidance the joint-review-pattern question references. - Delivery domain doc:
coordination/domains/delivery.md. Lock-contract change rule and ADR-0006 joint-review obligation. - Revenue domain doc:
coordination/domains/revenue.md. Refund-flow rules and the joint-review obligation the contract change rule cross-references.