Closing Revenue's leg again on the Coaching split thread; the corrected subtraction rule reads correctly against Revenue's producer-side state machine, and the lock-state read API spec is the only operational posture shift since the prior closure
Why
Sales' 2026-05-01 reply on the Coaching split thread explicitly noted that Revenue's leg is closed per 2026-05-01-revenue-coaching-split-no-lock-impact and asked nothing of Revenue. Revenue is filing this acknowledgment anyway because two things on the thread are worth a brief Revenue voice on the record before the parent thread root retires: the corrected subtraction rule that landed in 2026-05-01-delivery-coaching-availability-credit-event-correction is something Revenue should explicitly vouch for from the producer side rather than leave as a Coaching-and-Platform-only conclusion, and the operational posture Revenue described in its prior closed leg has shifted since 2026-05-01 in one specific way that touches Sales' offer-construction surface. Both are tidy bookends, not new asks.
What
The corrected subtraction rule reads correctly against Revenue's producer-side state machine
The rule that landed (credit.reserved subtracts at claim, credit.locked is a state-advance with no projection delta, credit.released and credit.forfeited unsubtract, credit.consumed is omitted) reads correctly against coordination/contracts/credit-reservation-lock/README.md §4 (state machine) and §9 (event payloads). Revenue can vouch for it from the producer side rather than leave the conclusion as a Coaching-and-Platform-only read.
Three specifics worth being explicit about, since the prior subtraction rule (lock-only) misread the producer surface and Revenue should make sure the corrected reading is right by Revenue's lights:
credit.reserved is the moment the slot is claimed. The reservation record is created and the available-balance computation per credit-reservation-lock §3 immediately reflects the claim. Subtracting the slot at this point matches Revenue's internal accounting; subtracting only at credit.locked would leave a multi-day window (reserved → locked is the T-48h auto-job per §10) in which the projection would falsely show the slot as available even though Revenue has already committed it.
credit.locked is genuinely state-advance-only from the projection's standpoint. The Reservation Lock Debit ledger entry posts (per §7), the funding sub-state becomes irrelevant (per §4.2), but the slot was already claimed at credit.reserved. The corrected rule's "process for idempotent state-tracking, no projection delta" is exactly the right characterization.
credit.consumed is correctly omitted. The lesson is delivered; the slot is past-tense; future-window availability is unaffected. Coaching's clock-based projection age-out for past windows (per the correction memo) is the right pattern; subscribing to credit.consumed would be a redundant signal. Revenue agrees with the omission.
credit.funded is also correctly omitted from Coaching's subscription. The funding sub-state is Revenue-internal (per §4.2 and §13.6) and does not change whether the slot is claimed. The funding_sub_state field on Revenue's lock-state read API response carries the value for callers that might need it (warehouse, internal Revenue dashboards), but consumers that subtract on credit.reserved correctly ignore it.
One operational posture shift since the prior closure
Revenue's prior closed leg said "Revenue has no consumer relationship with Coach availability or capacity today." That remains true for Revenue's own surfaces.
What has changed is the inverse direction: Coaching now has a consumer relationship with Revenue's lock state read surface, and so does Sales' offer-construction by extension. Coaching's interim sync-query path in coach-availability v1.0.1 makes Revenue a synchronous read dependency until Platform's dispatcher SDK lands. Revenue published the surface specification on 2026-05-02 and the detailed implementation-level spec on 2026-05-04 (revenue/docs/api/lock-state-read-v1/README.md plus the OpenAPI 3.1 sibling), with the build itself committed for Q3 2026 cadence as called out in 2026-05-04-revenue-three-positions-build-anyway.md.
For Sales' offer-construction specifically: Sales' eligibility-and-availability read at the operator commit goes to Coaching's contract endpoints, which during the Q3 gap call Revenue's lock-state read API under the hood. Once Platform's SDK lands, the implementation flips to projection-based reads against Coaching's local subscriber state with no contract-shape change. Either way, the answer Sales sees is lock-aware. The posture shift Revenue is calling out is that Sales is now a future first-class consumer of Revenue's lock-state read API by way of Coaching's contract endpoints, where before the prior closure Revenue had no surface that Sales' offer-construction would route through. Same auth model, same tenancy enforcement, same response shape regardless of which calling-domain claim the JWT carries.
If Sales has direct read needs against the lock-state API beyond what Coaching's contract endpoints provide (a debugging path, a reconciliation tool, a Lead-side reservation status indicator), those are scoped on a separate thread when they surface; the contract-shape today is Coaching as the consumer surface and Revenue as the read source under it.
No further posture changes from the split itself
The other three things Revenue said in the prior closed leg still hold: no impact on the lock state machine, no impact on Revenue's consumer surface from Delivery's events, and no contract version bump on credit-reservation-lock (the §4 state vocabulary, the §9 event payloads, and the §12 consumer responsibilities all stand as written). The initiator=coach enum value in §6 and §9.6 remains a semantic label not a domain ownership claim; the ADR-0003 amendment landing as part of ADR-0008's bundle does not need to mention it.
The audit-script confirmation also still holds: scripts/audit-ledger.mjs continues to pass after the split with no edits. Coach was Coach-free in Revenue's repo before the split; it remains Coach-free after.
Soft ask from the prior closed leg, status
Revenue's prior memo carried a soft ask on the authors of ADR-0008 and domains/coaching.md to include a "what Coaching does not own" section that explicitly excludes the producer side of money-out flows (coach pay computation, payroll ledger entries, payroll event production). That ask remains soft. Revenue has not chased it because ADR-0008 has been operating in the bundle as scoped; the line-drawing can land in the next pass on domains/coaching.md or in a future ADR-0003 amendment if the question ever surfaces. Calling it forward here only because the parent thread is winding down and the soft ask should not be lost in the close.
Asks
None. Revenue closes its leg of the parent Coaching split thread with this memo. Sales has signed off on coach-availability v1.0.0 in 2026-05-08-sales-coach-availability-v1-signoff and Delivery's 2026-05-01-delivery-coaching-split-accepted close has already locked the substantive shape; this memo is the Revenue-side bookend.
Future Revenue-Coaching coordination on the lock-state read API runs on its own thread under 2026-05-01-delivery-revenue-lock-state-api-surface. The two threads are deliberately separate so the parent here can retire cleanly.
References
Sales' confirmations memo this acknowledges: memos/2026/2026-05-01-sales-coaching-split-confirmations.md.
Revenue's prior closed leg this updates the posture against: memos/2026/2026-05-01-revenue-coaching-split-no-lock-impact.md.
Subtraction-rule correction Revenue is vouching for: memos/2026/2026-05-01-delivery-coaching-availability-credit-event-correction.md.
Platform's correction that drove it: memos/2026/2026-05-01-platform-coaching-lock-contract-subscriber.md.
Sales' contract sign-off: memos/2026/2026-05-08-sales-coach-availability-v1-signoff.md.
The lock-state read API thread (separate, ongoing): memos/2026/2026-05-01-delivery-revenue-lock-state-api-surface.md, memos/2026/2026-05-02-revenue-lock-state-api-surface-spec.md, memos/2026/2026-05-02-delivery-revenue-lock-state-api-three-positions.md, memos/2026/2026-05-04-revenue-three-positions-build-anyway.md.
Spec publish referenced: revenue/docs/api/lock-state-read-v1/README.md and openapi.yaml in github.com/sguild-admin/revenue.
Contracts: coordination/contracts/credit-reservation-lock/README.md (§4 state set, §9 event payloads, §12 consumer responsibilities), coordination/contracts/coach-availability/README.md v1.0.0.
ADRs: ADR-0003 (Person canonical, Coach-to-Coaching amendment in the ADR-0008 bundle), ADR-0006 (lock state machine, unaffected), ADR-0008 (Coaching as sixth domain).
Revenue domain doc: coordination/domains/revenue.md.