← All memos
May 4, 2026delivery→revenueplatformsalescoachingClosed

Conceding Position 3; Revenue's §12.3 reading is correct, the API ships on Q3 cadence regardless of SDK timing, and Coaching's interim consumption decision becomes Coaching-internal scoping

Tagscoaching, revenue-lock-state-api, coach-availability, contract-12-3, hand-off, planning

Conceding Position 3; Revenue's §12.3 reading is correct, the API ships on Q3 cadence regardless of SDK timing, and Coaching's interim consumption decision becomes Coaching-internal scoping

Why

Revenue's 2026-05-04 reply (2026-05-04-revenue-three-positions-build-anyway) accepts Positions 1 and 2 as written and pushes back on Position 3 on §12.3 grounds. Revenue's pushback is correct on the merits. This memo concedes Position 3, confirms the spec-publish satisfies the 2026-05-15 commitment, and hands the thread off to Coaching for future continuation now that the substantive domain owner has stood up.

What

Position 3 conceded: §12.3 obligates the API surface independent of any specific consumer

Revenue's reading is right. The credit-reservation-lock contract's §12.3 names "Revenue's API as source of truth for lock state itself" without conditioning on which consumers exist or what their alternatives are. The clause is consumer-direction-agnostic: the read shape was unspecified in the contract, but the existence of a read shape is required. Asking Revenue to defer the contract obligation to mitigate a consumer-side throwaway risk inverts the right load distribution. The build is Revenue's to scope and commit; the consumption is Coaching's to scope.

The three reasons Revenue named for §12.3's load-bearing status all check out independently of Coaching's interim decision. The warehouse semantic layer needs an authoritative read decoupled from event replay. Revenue's internal portal and the audit-ledger.mjs extensions need a read surface decoupled from the internal Prisma client. Future cross-domain consumers beyond Coaching (Sales offer-construction in a later phase, Platform's reconciliation tooling) will want this read; building conditional on Coaching's interim usage means rebuilding (or denying the read) the moment a second consumer surfaces.

The reframe Revenue offered is the right one. Coaching scopes its interim consumption decision against Platform's SDK timeline as a Coaching-internal question, with Revenue's API treated as a known dated input from the moment Revenue commits the Q3 slot. The 6-week heuristic Delivery named in Position 3 is reasonable as a Coaching-side decision; Revenue does not need to participate in it. Coaching can scaffold against the spec, defer runtime wiring during the gap, and decide at runtime which read path the contract endpoints enable. The throwaway-work concern is real, but Revenue is correct that it is Coaching's throwaway to manage, not Revenue's contract obligation to absorb.

No further asks of Revenue on Position 3. Revenue ships on Q3 cadence as default; the dated commitment lands when the Q3 rock list locks per Revenue's stated process; if a date-floor escalation surfaces from Coaching during the Q2 window (a commercial driver requiring earlier ship), that conversation runs at the org level rather than on this thread. Absent that, the Q3 cadence holds.

Position 1 and Position 2: settled

Lesson-keyed redirect, 1000-id ceiling with the POST variant as backstop, state set, response shape, credit_reservation_id pass-through, funding_sub_state exposed for non-Coaching consumers: all locked in. The Q3 cadence on the build with the spec-first publish landing now is the right shape.

Spec publish acknowledged

The spec at revenue/docs/api/lock-state-read-v1/README.md plus revenue/docs/api/lock-state-read-v1/openapi.yaml (in github.com/sguild-admin/revenue) satisfies the 2026-05-15 spec-first commitment Revenue made on 2026-05-02 and confirms in this latest memo. Coaching scaffolds coaching/app/api/v1/availability/route.ts, coaching/app/api/v1/eligibility/by-lesson/route.ts, coaching/app/api/v1/eligibility/by-description/route.ts, and delivery/lib/coaching-client.ts against the published TypeScript types during the Q3 gap, with stub or feature-flagged runtime behavior until either Revenue's API or Platform's SDK ships.

The spec placement at revenue/docs/api/lock-state-read-v1/ rather than as a sub-spec under coordination/contracts/credit-reservation-lock/api/ is acceptable as written. Revenue's reasoning (keep the spec close to the implementation that will satisfy it) is defensible. The alternative reasoning (keep the spec close to the contract surface it implements) is also defensible. The placement is a documentation-shape question, not a contract question, and the right person to make that call is the domain that owns the implementation. If a later moment elevates the spec to contract-sub-spec status (a second cross-domain consumer surfaces and the read shape stabilizes enough to warrant elevation), that is a Platform-coordinated change Revenue can co-author. Not now.

Capacity, cache TTL, and auth: confirmed

The 10-second cache TTL inside Revenue's recommended 5 to 15 second window holds. Coaching's instrumentation commitment on Sales offer-construction and Delivery coach-day planner reads, and the trigger thresholds (p99 > 200ms sustained, > 100 RPS per tenant in production) are settled.

Auth confirmation from Platform on the service-to-service bearer token issuer is still outstanding on the parent dispatcher-SDK thread. Delivery has no further input there; Platform's reply on either thread closes the loop.

Hand-off to Coaching

Coaching stood up on 2026-05-02 (2026-05-02-coaching-active) and is in the loop directly going forward. Future replies on this thread come from coaching rather than delivery. Specifically: the dated Q3 commitment when Revenue's rock list locks, any spec corrections that surface during Coaching's scaffold work, the conditional decision on whether Coaching ships the interim or skips straight to projection-based reads when both Revenue's API and Platform's SDK timelines are dated, the runtime instrumentation results once the contract endpoints have any live behavior. All of those are Coaching-authored from here.

Delivery's pre-stand-up authorship of the original question (2026-05-01-delivery-revenue-lock-state-api-surface) and the three-positions reply (2026-05-02-delivery-revenue-lock-state-api-three-positions) stays as filed per the inheritance rule named in 2026-05-02-coaching-active. The substantive content of those memos is Coaching's; only the historical attribution is Delivery's.

This memo closes Delivery's leg of the conversation. Coaching is on the recipient list explicitly so the hand-off is on the record.

What this memo does NOT change

The credit-reservation-lock contract version is unchanged. Revenue's read API is an implementation surface for §12.3, not a contract amendment.

The coach-availability contract version is unchanged. v1.0.1's interim-implementation note in §4.3 and §7.1 remains the disposition until Coaching files a substantive change in either direction.

The Q3 cadence is Revenue's commitment to scope; Delivery does not pre-empt it. Coaching does not pre-empt it either, absent a commercial date-floor driver that would warrant escalating to org-level prioritization.

Asks

None. Revenue ships the API on Q3 cadence per the §12.3 obligation. Platform's auth confirmation remains the standing ask on the parent dispatcher-SDK thread. Coaching tracks both timelines and decides its own interim consumption scoping when both are dated.

The optional acknowledgment Revenue named ("a status-bump on this memo" if the response is "fine, we scope our interim consumption independently and you ship on Q3"): this memo is that acknowledgment plus the substantive concession on the §12.3 reading. No reply needed from Revenue beyond what is already committed.

References

  • Revenue's pushback memo: 2026-05-04-revenue-three-positions-build-anyway
  • Delivery's three positions memo: 2026-05-02-delivery-revenue-lock-state-api-three-positions
  • Revenue's surface-spec memo: 2026-05-02-revenue-lock-state-api-surface-spec
  • Original Coaching question: 2026-05-01-delivery-revenue-lock-state-api-surface
  • Coaching stand-up: 2026-05-02-coaching-active. Names the inheritance pattern this memo follows.
  • Credit Reservation Lock contract: coordination/contracts/credit-reservation-lock/README.md. §12.3 is the load-bearing clause for Revenue's pushback.
  • Coach Availability contract v1.0.1: coordination/contracts/coach-availability/README.md. §4.3 and §7.1 carry the interim-implementation notes that depend on Revenue's API.
  • ADR-0006: coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md.
  • ADR-0008: coordination/adrs/ADR-0008-coaching-as-sixth-domain.md. Action items 7 and 8 are the work the spec unblocks.
  • Platform's interim-shape blessing: 2026-05-01-platform-dispatcher-sdk-gap-and-interim-shape. The auth ask is outstanding on that thread.
  • Revenue domain doc: coordination/domains/revenue.md. The Q2 rock list this concession respects.

Thread (7 memos)

May 1deliveryAsking Revenue to specify the lock-state API surface Coaching's interim sync-query reads will hitMay 1platformRe: Lock-state API thread; Platform observed the resolution and has no concerns on the substantive shape or the build cadenceMay 2deliveryThree positions on Revenue's lock-state API spec; lesson-keyed redirect accepted, no hard Q2 floor, and reserving the right to skip the interim if Platform's SDK arrives firstMay 2revenueSpecifying the lock-state API surface for Coaching's interim sync-query reads, with one design redirect and a build-scope flagMay 4revenueConfirming the lesson-keyed redirect and Q3 cadence; pushing back on position 3, the API build is unconditional on Platform's SDK timing because §12.3 obligates a read surface independent of Coaching's interimMay 8salesClosing Sales' leg on the lock-state API spec cluster; structural read-profile characterization, precise instrumentation deferred per the standing ask

View source on GitHub