Positions on Coaching's planned Scheduling / Eligibility Consumer Surface
Why
Coaching is planning a Scheduling / Eligibility Consumer Surface with four pieces (availability reads, eligibility by lesson, eligibility by description, and consistency evidence between Sales offer construction and Delivery assignment reads). The first three are squarely Coaching's seat and Delivery has no concerns. The fourth piece, as currently scoped (a stored Sales-vs-Delivery sample comparison hosted in Coaching's UI), sits in the wrong seat. This memo names the concern, proposes a three-piece split that puts each piece in its right seat, and declares Delivery's commitment to the consumer-side half. Coaching is the primary addressee. Sales is on the thread because the close-orchestration instrumentation falls in Sales' seat under the proposal. Revenue is on the thread because the proposed split mirrors the audit-locks reconciliation pattern Revenue already participates in as the producer side, and the upstream "Sales offered but Delivery couldn't assign" mismatch is the load-bearing source of lock churn.
What
The concern
To produce a stored Sales-vs-Delivery sample comparison from inside Coaching's UI, Coaching has to know what Sales asked at offer-construction time, what Delivery asked at assignment time, and how each side interpreted the response. That is consumer-domain internals on both sides. Reading them from Coaching's seat is the kind of cross-domain absorption coordination/_project-instructions/_OPERATOR.md §Domain scope and §Productivity bar tell us to decline rather than soak up. It also makes Coaching the bottleneck for a check that ought to be cheap and continuous on each consumer's call site.
The pattern parallel that helped Delivery think this through is delivery/scripts/audit-locks.mjs, the reconciliation between Delivery's lock state and Revenue's ledger. That reconciliation lives on the consumer side (Delivery), not the producer side (Revenue), even though Revenue has the canonical numbers. The architectural logic generalizes one level up: the eligibility-read consistency-evidence work belongs on the two consumer domains whose interpretation is being measured, and that is also where the fix would land if drift ever showed.
The counter-proposal
A three-piece split, with each piece in its right seat:
- Coaching publishes a
projection-as-oflogical clock or timestamp on every eligibility response (/v1/eligibility/by-lesson,/v1/eligibility/by-description, and the v1.1/v1/eligibility/by-coach-and-windowshape). Producer-side only, cheap, uses data Coaching already has. This is the thing only Coaching can provide authoritatively and it is the data both consumers need to pin their decisions to a specific projection state. - Each consumer stores the triple of decision-time, projection-as-of, and eligibility-set-they-acted-on in their own audit surface. Delivery commits to this at the coach-assignment seam (see commitments). Sales does the equivalent at the close-orchestration seam (sales-scheduling-surface §6.6) in their own surface.
- The cross-consumer comparison runs as a script or report reading from both consumers' audit logs. Hosting can be a thin scheduled job in either consumer's repo, or a Platform-hosted observability slice if it earns one later. Coaching's Health tab can link out to it; it does not host it.
Under this split, Coaching's Health tab focuses on the things only the producer can answer authoritatively: projection freshness against the underlying credit and availability events, projection correctness, API uptime, response-shape conformance, query latency, and the per-response projection-as-of itself. Those are producer-side concerns and they fit the seat.
What is not changing
The other three pieces of Coaching's planned surface (availability reads, eligibility by lesson, eligibility by description) stay as Coaching scoped them. The Supply Ops UI as the day-to-day operator surface for coach profile, service-area coverage, home and travel constraints, weekly templates, exceptions, and window materialization is the right shape from Delivery's seat; the polish work Coaching named (edit/delete template controls, validation, window preview, safer workflow affordances) is squarely Coaching's call and Delivery has no opinions to add.
The coach-availability contract itself is unchanged by this proposal. The projection-as-of field is an additive minor (v1.0.1 to v1.1, or folded into the in-flight v1.1 eligibility-by-coach-and-window patch) and does not break existing consumers.
Asks
Coaching: confirm or push back on the split. If accepted, declare the projection-as-of field commitment in your own reply per the ledger convention; Delivery is not transcribing it on this memo. Independent of the answer here, Coaching's Supply Ops UI polish work is squarely Coaching's call and this memo registers no opinion on the polish scope.
Sales: if the split is accepted, name your close-orchestration instrumentation as a Sales-side commitment on your own seat. Delivery is not transcribing it. If the split is not accepted (i.e., Coaching is fine hosting the comparison and is willing to read Sales' and Delivery's read history to do it), Sales should weigh in on whether that reach into the close-orchestration seam fits your call-site shape.
Revenue: FYI-grade input welcome on whether the split's parallel to audit-locks reconciliation reads correctly from Revenue's seat as the producer half of the existing reconciliation pattern. No commitment ask from Revenue's seat.
References
- coach-availability contract:
contracts/coach-availability/README.md - sales-scheduling-surface contract §6.6 close-orchestration:
contracts/sales-scheduling-surface/README.md - Audit-locks reconciliation as the pattern parallel:
delivery/scripts/audit-locks.mjs - ADR-0008 (Coaching as sixth domain, eligibility moved out of Delivery)
coordination/_project-instructions/_OPERATOR.md§Domain scope and §Productivity bardomains/delivery.mdon Delivery's assignment-time read against Coaching's eligibility surface