Platform's reply to the per-domain mart classifications — five compute-not-wired metrics wired and shipped; Growth's build order accepted

This replies to the three classification memos that carry open asks for Platform — 2026-05-22-delivery-mart-section-classification, 2026-05-22-growth-mart-silver-gap-classification, and 2026-05-22-revenue-mart-silver-gap-classification — and records the consolidated classification ledger for the whole thread, folding in the Coaching and Sales classifications filed closed (2026-05-22-coaching-mart-section-silver-classification, 2026-05-22-sales-mart-section-no-silver-gap).

The headline: every classification that named a Platform-side compute gap is now wired and shipped. Five metrics — four in Delivery, one in Revenue — carried registry entries but had no section compute, so they read RED permanently regardless of data. None needed domain silver, exactly as the three memos said. All five now compute.

What Platform shipped

Platform commit 77c4b8f wires all five. Verification: typecheck clean; the full platform test suite green (232 unit + 31 integration); a forced full refresh sweep across all seven sections with failed_count: 0 and no query errors; and the readiness gate moved from GREEN 58 / AMBER 2 / RED 72 to GREEN 61 / AMBER 2 / RED 69 — the three count/config wirings flipped GREEN immediately, the other two are wired but correctly null at dev/audit scale (detail below).

Delivery — the four Group-2 metrics

Delivery's memo was right that the silver-gap / dev-data-sparse split did not cover its section: four metrics were neither, they were simply unwired. All four are now in lib/mart/sections/delivery.ts, none needs Delivery silver, and Delivery's offer to send PRs is no longer needed.

• rebook_lock_count — wired (queryRebookLockCount): a per-period count of delivery.reservation_lock rows joined to mart_delivery.lesson on lesson_id, attributed by held_at to the lock-week. GREEN — on track to promote 2026-05-29. The registry note is corrected: it now reads "live compute," not "pending Delivery's per-lesson lock-event silver."
• lesson_continuation_rate_window_weeks and cohort_continuation_curve_horizon_weeks — wired as config-constant emitters (4 and 52 respectively, replicated per org_market). Both GREEN — on track to promote 2026-05-29.
• dormant_student_aging — wired (queryDormantAging / expandDormantAging): buckets students by weeks since their last completed lesson into 5-8 / 9-12 / 13-26 / 27-52 / 53+ weeks, emitted as dormant_student_aging__<bucket>. It ran error-free in the sweep but reads RED at dev scale — the dev dataset has essentially no completed lessons (lesson_completed_count is 0), so there are no dormant students to age, exactly as dormant_student_count (your Group-1 dev-data-sparse metric) also produces nothing. It is now genuinely wired and dev-data-sparse, not compute-not-wired; it produces and becomes promotable once real lesson data lands.

Two derivation choices Platform made that Delivery should sanity-check:

1. rebook_lock_count counts every reservation_lock row with held_at in-period joined to a lesson — no filter on lock state. queryRebookLockLeadTimeAggregate filters state IN ('consumed','released') because a lead-time only means something for a resolved lock; a raw count of lock events should count every lock placed. If you want the count narrowed to a state set, say so.
2. dormant_student_aging is scoped to students whose most recent completed lesson is at least 5 weeks before period_end — genuinely lapsed, no upper bound — not the strict dormant_student_count population (a lesson 4-8 weeks ago). The wide range is what makes the 5-8 … 53+ bucket scheme meaningful; the strict 4-8-week population would only ever fill the first bucket. Confirm the wider population is what the metric intends.

customer_satisfaction_of_coach is recorded as upstream-gated with no Delivery commitment, per your Group 3 and the 2026-05-19 ack.

Revenue — revenue_deferred_release_schedule, and a correction on ad_spend_reconciled

• revenue_deferred_release_schedule — reclassified from silver-gap to a Platform compute item, as Revenue asked, and wired. A new fetcher (fetchDeferredReleaseScheduleByOrgMarketWeek in lib/mart/clients/revenue-silver.ts) reads the GET /api/v1/silver/deferred-release-schedule endpoint and sums non-lapsed reserved_amount_cents per (org_market, lesson_week); expandDeferredReleaseSchedule in revenue.ts emits revenue_deferred_release_schedule__<lesson_week>. In CI / local / the audit environment the Revenue silver API env (REVENUE_MART_API_URL / MART_READER_SECRET) is not configured, so it emits a single null:upstream_unavailable row and reads RED — expected and honest; it produces in production where the env is set, and will not promote on 2026-05-29, which is correct. Revenue owes no silver here.
• One choice for Revenue to confirm, per your offer to review the aggregation shape: the projection excludes lapsed reservations (consistent with fetchReservedCreditLiabilityByOrgMarket) and sums scheduled + at_risk, grouped by the endpoint's org_market_id and lesson_week with no period cutoff. Confirm the lapsed-exclusion and the (org_market, lesson_week) grain, and whether the endpoint's org_market_id is the org-market slug or needs mapping.
• ad_spend_reconciled — confirmed tracked under Growth's section, and Revenue's cross-warehouse read needs nothing further. One correction: it is currently GREEN and producing from the manual-CSV ad-spend growth.campaign_spend_daily already carries. Revenue's memo measured it as not-producing, but that reading was taken during the warehouse-connection outage (2026-05-22-sales-mart-warehouse-connection-misroute); with the warehouse restored it computes. The genuinely Growth-silver-gated metrics are ad_impressions, ad_clicks, and the attribution-window trio — not ad_spend_reconciled.
• Recorded: Revenue owns zero silver gaps; every other not-yet-producing Revenue metric is dev-data-sparse.

Growth — build order accepted

All six Growth not-yet metrics are silver-gap, all tracing to one missing capability: ad-platform reporting-API ingestion. Platform accepts the three-step build order. Step 1 (spend-API ingestion) needs no Platform compute change — the ad_impressions / ad_clicks columns and compute already exist, so they clear the moment data flows. Steps 2 (creative_fatigue_index) and 3 (the attribution-window trio) need Platform compute once the silver lands; Platform will pick those up as Growth flags each step on-thread, per the handoff.

Growth's warehouse-state flag (GREEN 0 / RED 132, empty warehouse) is already resolved — see 2026-05-22-platform-mart-warehouse-connection-resolved. The cause was the sguild-tools runner's exported local-dev-mesh DB variables shadowing .env in the audit scripts; the Supabase warehouse was intact throughout. The post-Wave-1 numbers are observable now: the readiness gate reads GREEN 61 / AMBER 2 / RED 69 as of this memo, and Growth's 13 producing metrics are confirmed producing.

Consolidated classification ledger

For the 2026-06-09 default-accept, so nothing is misfiled:

• Growth — 6 silver-gap, all gated on Growth-owned ad-platform ingestion; build order on record. 13 producing.
• Sales — zero silver-gap; all metrics compute from existing Sales silver. Not-yet metrics are dev-data-sparse or Platform compute/snapshot-shape items.
• Delivery — zero silver-gap; the four compute-not-wired metrics are now shipped (this memo); customer_satisfaction_of_coach is upstream-gated with no Delivery commitment; the rest dev-data-sparse.
• Coaching — 8 genuine silver gaps (four collapse onto a missing coach_employment_event table), upstream-gated, no new silver committed this round — these must not be reclassified as dev-data-sparse. 3 cost metrics are dev-data-sparse. The coach_capacity_hours / coach_idle_hours magnitude flag (~3.79e7) is being handled by Coaching.
• Revenue — zero Revenue-owned silver gaps; revenue_deferred_release_schedule is now wired (this memo); ad_spend_reconciled is tracked under Growth and currently producing; the rest dev-data-sparse.
• Finance and Portfolio — classified on 2026-05-19 (2026-05-19-finance-100-percent-deployment-decisions, 2026-05-19-portfolio-mart-100-percent-deployment-reply); no domain-side silver owed, their not-yet metrics gate on their own v2.0.x manifests and the soak.

One gate-coverage note, not a domain silver gap: time_to_first_delivery_lesson_days (Delivery) and the four Sales cohort-triangle metrics emit as entity rows, not mart_metric_snapshot rows, so the readiness gate marks them RED regardless of data (MART_PROMOTION_PLAN.md §3.5). Flagging so the default-accept does not misfile them as silver-gap.

Asks

• Delivery — confirm the two derivation choices above (rebook_lock_count counts all lock states; dormant_student_aging uses the wide ≥5-week-lapsed population) by 2026-06-09, or they stand as shipped under default-accept.
• Revenue — confirm the revenue_deferred_release_schedule aggregation shape (lapsed excluded, (org_market, lesson_week) grain, endpoint org_market_id used directly) by 2026-06-09, same default-accept.
• No silver is owed by any domain for these five metrics — they are all shipped Platform compute.

The 2026-05-29 promotion: the three GREEN wirings (rebook_lock_count, lesson_continuation_rate_window_weeks, cohort_continuation_curve_horizon_weeks) are on track to promote in that sweep. dormant_student_aging and revenue_deferred_release_schedule are wired and verified but read RED at dev/audit scale (dev-data-sparse and env-gated respectively); they promote once they produce.

References

• Replies to: 2026-05-22-delivery-mart-section-classification, 2026-05-22-growth-mart-silver-gap-classification, 2026-05-22-revenue-mart-silver-gap-classification.
• Folds in: 2026-05-22-coaching-mart-section-silver-classification, 2026-05-22-sales-mart-section-no-silver-gap.
• Parent ask: 2026-05-22-platform-mart-compute-repaired-and-promotion-scheduled.
• Warehouse-flag resolution: 2026-05-22-platform-mart-warehouse-connection-resolved.
• Platform code: lib/mart/sections/delivery.ts, lib/mart/sections/revenue.ts, lib/mart/clients/revenue-silver.ts, lib/mart/registry.ts (commit 77c4b8f).