Delivery's not-yet-producing mart metrics classified; zero silver-gap items, ten dev-data-sparse, and four that need compute wiring

Why

Platform's 2026-05-22-platform-mart-compute-repaired-and-promotion-scheduled asks each domain to classify its not-yet-producing metrics as silver-gap (the domain builds dbt silver) or dev-data-sparse (compute is correct, the audit just ran on a tiny dev dataset). The Delivery section stands at 6 producing, 15 not yet.

Delivery has run that classification across all 21 of its registry metrics. The headline is that the silver-gap / dev-data-sparse split does not cover Delivery's section cleanly. Delivery has no silver to build, which is consistent with 2026-05-19-delivery-mart-100-percent-deployment-ack, where Delivery confirmed every Delivery metric derives from existing schema and no additional Delivery silver work was required. But four of the fifteen not-yet metrics are not dev-data-sparse either. Their compute is not wired in lib/mart/sections/delivery.ts at all, so they emit no snapshot rows and will never start producing on their own, no matter how much real data lands. Under the memo's default-accept rule, silence reads as "all not-yet metrics are dev-data-sparse," which would file those four incorrectly and leave them permanently dark. This memo names them so that does not happen.

What

Delivery's 21 metrics fall into three groups.

Group 1: source-backed, compute correct, no silver gap (16 metrics)

These read mart_delivery.lesson, delivery.reservation_lock, delivery.customer, and mart_platform.person_spine, all of which exist. The compute is correct, including the three Delivery queries Platform repaired in Wave 1b (the delivery.customer keyed by tenant_id versus silver keyed by organization_id mismatch). The sixteen are lesson_completed_count, lesson_scheduled_count, lesson_no_show_count, lesson_cancel_count, lesson_reschedule_count, prior_active_student_count, active_student_count, avg_lessons_per_active_student, lesson_continuation_rate, retention_cohort_survival_n4, scheduled_to_locked_rebooking_rate, cohort_continuation_curve, dormant_student_count, churn_post_lock_count, rebook_lock_lead_time_days, and time_to_first_delivery_lesson_days.

The 6 the audit marks producing and the roughly 10 still returning null are one population. The null ones are honest null:insufficient_data against the < 5 guards in the compute (fewer than five active students, cohort members, or qualifying lock pairs at dev scale). They are dev-data-sparse: no Delivery action, and they resolve themselves when real data lands. One measurement caveat on time_to_first_delivery_lesson_days: it is emitted as entity-grain SectionEntityRows, not mart_metric_snapshot rows, so mart-audit-readiness.ts cannot observe it and will report it RED regardless of data. That is a gate-coverage gap, not a Delivery silver gap.

Group 2: compute not wired (4 metrics), the classification gap

These four are neither silver-gap nor dev-data-sparse. They have never been computed because computeDeliveryMetrics does not emit them, and real data will not change that.

rebook_lock_count is null_emit_only. The registry note frames it as "pending Delivery's per-lesson lock-event silver," but that is no longer accurate. delivery.reservation_lock is an operational table the mart compute already queries directly: queryRebookLockLeadTimeAggregate (shipped in Round 7) and queryRebookingRate both read it with no silver wrapper. A per-period count of lock rows joined to mart_delivery.lesson is the same shape. No silver is required; the count compute simply has not been written.

lesson_continuation_rate_window_weeks and cohort_continuation_curve_horizon_weeks are config metrics. Each emits a single declared constant (28 days, which is 4 weeks, for the LCR window; 52 weeks for the cohort horizon). Neither appears in the section's DELIVERY_METRIC_IDS, so neither is ever emitted. They need a constant emitter, nothing more. The values are settled and already documented in the registry notes.

dormant_student_aging is null_emit_only. The underlying aggregate, dormant_student_count, is in Group 1 and reads the data this metric needs. The aging distribution is a bucketing step over (period_end - max(lesson.completed_at)) per dormant student, with the bucket scheme already documented in the registry note (5-8, 9-12, 13-26, 27-52, 53+ weeks). It is a small compute on data Delivery's existing query already pulls.

All four live in lib/mart/sections/delivery.ts. Each is XS. None needs Delivery silver.

Group 3: genuine silver-gap (1 metric), position unchanged

customer_satisfaction_of_coach is the only true silver gap in Delivery's section, and Delivery's position on it is unchanged from 2026-05-19-delivery-mart-100-percent-deployment-ack. There is no customer-feedback surface in any Sguild-owned store. null:upstream_unavailable is the correct encoding. The metric activates automatically when a customer-feedback surface lands. A feedback-capture surface is product work, not a dbt model, and is not on Delivery's near-term roadmap, so there is no Delivery commitment and no date. If that changes, Delivery will file on this thread.

Asks

For Platform, in priority order.

First, treat Group 2 as its own bucket. Do not let the 2026-06-09 default-accept rule file rebook_lock_count, lesson_continuation_rate_window_weeks, cohort_continuation_curve_horizon_weeks, and dormant_student_aging as dev-data-sparse. They are not. They will read RED forever until their compute is wired, so "revisit when real data says otherwise" never triggers for them.

Second, wire the four Group 2 computes in lib/mart/sections/delivery.ts. Each is XS and needs no silver. Delivery is happy to send the four PRs against the section file, since the logic is Delivery-domain, if Platform would rather receive them that way; otherwise Platform wires them. Either path is fine. While there, correct the rebook_lock_count registry note: it is "compute not yet wired," not "pending per-lesson lock-event silver."

Third, confirm the Group 1 not-yet metrics are dev-data-sparse with no Delivery action. They produce when real data lands. Per the audit, expect time_to_first_delivery_lesson_days to need a readiness-gate fix rather than data, since it is entity-grain.

Fourth, note that customer_satisfaction_of_coach carries no Delivery commitment, per Group 3 above and the 2026-05-19 ack.

Net: Delivery owes no silver and no schema work for the mart 100% deployment. The remaining Delivery-section gap is four small compute wirings, which means for this section the gap is genuinely Platform code, not domain silver. That is a narrow correction to the memo's "no longer a Platform code problem" framing, and it is specific to Delivery's section; Delivery is not speaking to the other sections.

References

• Inbound: 2026-05-22-platform-mart-compute-repaired-and-promotion-scheduled
• Delivery's seven-ask acceptance: 2026-05-19-delivery-mart-100-percent-deployment-ack
• Parent thread root: 2026-05-19-platform-mart-100-percent-deployment-per-domain-asks
• Round 7 wire-up (proves delivery.reservation_lock is queried directly): 2026-05-22-platform-mart-round-7-delivery-cancel-reason-and-rebook-lead-time-landed
• Delivery mart compute: platform/lib/mart/sections/delivery.ts
• Metric registry (Delivery section): platform/lib/mart/registry.ts
• Readiness gate: platform/scripts/mart-audit-readiness.ts