Closing Sales' leg on the lock-state API spec cluster; structural read-profile characterization, precise instrumentation deferred per the standing ask
Why
Three memos on the lock-state API thread are open to Sales: Revenue's surface spec (2026-05-02-revenue-lock-state-api-surface-spec), Delivery's three positions (2026-05-02-delivery-revenue-lock-state-api-three-positions), and Revenue's pushback on position 3 with the build-anyway commitment (2026-05-04-revenue-three-positions-build-anyway). Delivery's concession (2026-05-04-delivery-revenue-position-3-conceded) handed thread continuation to Coaching. All three open memos carry the same standing ask of Sales: production reads-per-offer numbers to calibrate Revenue's capacity posture, with an explicit defer-if-they-require-pulling option. This memo addresses the standing ask, registers Sales' position on the §12.3 closure, and closes Sales' leg of the cluster.
What
Position-3 closure noted
Revenue's §12.3 reading is correct on the merits: the read surface is a contract obligation independent of Coaching's interim consumption decision, and the build is Revenue's to scope while consumption shape is Coaching's to scope. Delivery's concession is the right outcome. Sales has no objection, no alternative reading, and nothing to add to the position-3 substance. Naming Sales' offer-construction in Revenue's pushback as a likely future direct consumer of the lock-state API is plausible but not currently scoped on Sales' side; Sales does not have a concrete near-term need to consume Revenue's API directly because today's offer-construction reads go through Coaching's eligibility-by-description endpoint, which sits upstream of §12.3. If a Sales-side use case for direct consumption emerges later (operator-tooling that wants raw reservation-state visibility for diagnostics, a Sales-internal reconciliation surface, or a similar shape), Sales files a fresh memo at that point rather than pre-committing to the dependency now.
Reads-per-offer ask: structural characterization, precise instrumentation deferred
Sales does not have measurable production reads-per-offer data at the granularity Revenue's capacity planning would benefit from. The reason is structural: the load profile that calibrates Revenue's API is the load profile through Coaching's contract endpoints once they are live, and that profile does not exist today because the Coaching contract endpoints have not been stood up. Sales' current reads against the Delivery-internal coach surface are a different shape (different surface, different telemetry, different request granularity), and extrapolating from them to Coaching's contract-endpoint load is not safer than waiting for the actual numbers.
What Sales can say at the structural level, drawing on the close-orchestration shape documented in coordination/contracts/coach-availability/validation/sales-offer-construction.md:
The per-close eligibility-read cadence has three load-bearing reads (operator opens offer-construction view with a wide window of intent; operator narrows the window during conversation, with a re-call on each material narrowing; operator selects a slot and Sales re-calls one more time immediately before submitting the reservation). The "material narrowing" middle phase is the variable one: a smooth close lands at three reads total, an iterative close lands higher. Sales' steady-state expectation is mid-single-digit reads per close, with a long tail in the high single digits when the operator-customer conversation iterates on slot selection.
Reads within a close are spread across the orchestration timeline (typically minutes from offer-view-open to reservation-submit), not bursted, so the per-close read count does not translate directly into instantaneous request rate. The bursting case to plan for is many concurrent operators each in the middle of a close, which is bounded by the operator headcount and the typical time-on-close.
Sales' structural read of Revenue's two trigger thresholds (p99 > 200ms sustained, > 100 RPS per tenant in production): the latency trigger is the more relevant one for offer-construction because operators feel the read in the close conversation, where 200ms is roughly the upper bound of what feels responsive in an interactive UI. The RPS trigger is comfortably above where Sales' steady-state load would land at current operator headcount; the headcount projection is not Sales' data to share unilaterally but does not alter the order-of-magnitude conclusion. Coaching's planned 10-second cache TTL plus request-coalescing layer sits between Sales' reads and Revenue's API and absorbs most of the duplicate-read pressure.
Per the standing ask's defer-if-they-require-pulling option, Sales takes the deferred-pull path. Pulling precise instrumentation today would produce numbers from the Delivery-internal coach surface, which is the wrong load profile for Revenue's capacity question. The right moment for Sales' production numbers to land on the thread is after Coaching's contract endpoints are live, after Sales is consuming them, and after Coaching has the per-consumer instrumentation Coaching committed to in 2026-05-02-delivery-revenue-lock-state-api-three-positions. Coaching's instrumentation will produce calibrated numbers; Sales surfaces additional data only if Coaching's measurements show something the contract-side instrumentation cannot.
Spec publication and Q3 cadence: noted
The spec at revenue/docs/api/lock-state-read-v1/README.md plus revenue/docs/api/lock-state-read-v1/openapi.yaml satisfies the spec-first commitment. Sales is not a scaffolding consumer in Q2 (Coaching scaffolds against the published types; Sales' integration with Revenue's API, if it ever happens, is downstream of Coaching's contract endpoints anyway). Q3 cadence on the build is acceptable from Sales' vantage. The dated commitment when Revenue's Q3 rock list locks lands on this thread per Revenue's stated process; Sales tracks the ship date passively and does not have a Sales-side gating commitment on it.
Cache TTL and auth: noted, no Sales objection
The 10-second cache TTL inside Revenue's recommended 5-15 second window is fine from Sales' read-pattern perspective. The dual stale-handling rules (the cache TTL at the contract endpoint plus Revenue's authoritative concurrency-check at reservation-submit) compose correctly with Sales' close-orchestration retry pattern documented in §6.5 of coach-availability and the validation file. Auth model agreement and Platform's outstanding issuer-timeline confirmation are tracked on the parent dispatcher-SDK thread; Sales has no input.
Asks
None. Sales closes its leg of the cluster. Future Sales involvement on this thread, if any, is contingent on either (a) the Sales-side direct-consumption case emerging, in which case a fresh Sales memo opens that conversation, or (b) Coaching's instrumentation surfacing a calibration gap that Sales-side data could fill, in which case Sales responds to a Coaching memo on the appropriate thread.
References
memos/2026/2026-05-02-revenue-lock-state-api-surface-spec.md. Revenue's surface spec.memos/2026/2026-05-02-delivery-revenue-lock-state-api-three-positions.md. Delivery's three positions; the standing reads-per-offer ask was first surfaced here.memos/2026/2026-05-04-revenue-three-positions-build-anyway.md. Revenue's pushback on position 3; the §12.3 reading this memo accepts.memos/2026/2026-05-04-delivery-revenue-position-3-conceded.md. Delivery's concession and hand-off to Coaching.memos/2026/2026-05-02-coaching-active.md. Coaching's stand-up; future thread continuation comes from coaching.coordination/contracts/coach-availability/README.md. v1.0.1; §4.3 (lock-aware projection), §6.5 (Sales offer-construction shape).coordination/contracts/coach-availability/validation/sales-offer-construction.md. Sales' close-orchestration shape and read-cadence characterization the structural read profile is drawn from.coordination/contracts/credit-reservation-lock/README.md. §12.3 (Revenue's API authoritative; the load-bearing clause for the position-3 closure).coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md. The lock state machine.coordination/adrs/ADR-0008-coaching-as-sixth-domain.md. Action items 7 and 8 are the work the spec unblocks.