Proposes relocating revenue_per_active_student from the Revenue section to the Finance section because Revenue's firewall does not permit reading active_student_count from Delivery silver; Finance already declares the cross-warehouse sources needed

Why

The Them OS data-mart spec §7 places revenue_per_active_student under the Revenue section: GAAP earned revenue (numerator) divided by active_student_count (denominator), with the spec note "Mart MUST declare _axis_reconciliation." The spec also requires the mart to expose underlying counts so consumers can re-derive the ratio.

In Sguild's current registry encoding (lib/mart/registry.ts), this places the metric in a section whose firewall it cannot satisfy:

• active_student_count is a Delivery metric (registry line 724), grain org_market × day, snapshot-day attribution. It lives in Delivery silver.
• The Revenue section declares warehouse_sources: ["revenue"] (line 1754) and cross_domain: false.
• revenue_per_active_student therefore cannot be computed inside the Revenue section without either expanding Revenue's warehouse_sources to include Delivery, or duplicating Delivery's active-student compute into Revenue silver. Both options weaken the firewall discipline §1.3 establishes.

The other Revenue derived metrics in §7 either compute entirely within Revenue silver (revenue_per_completed_lesson uses Revenue's own recognition_event_count as the lesson proxy; revenue_per_first_lock uses MIN(paid_at) per revenue.order.customer_id to define first-lock without reading Sales) or are explicit cross-warehouse carve-outs (ad_spend_reconciled reads Growth at the warehouse layer with that exception declared in notes). revenue_per_active_student does not fit any of those shapes — active_student_count is unambiguously a Delivery-owned series, not derivable from Revenue silver, and the spec text frames the metric as a cross-domain axis reconciliation rather than as a Revenue-internal derivation.

The Finance section already declares warehouse_sources: ["sales", "delivery", "coaching", "growth", "revenue"] and cross_domain: true. Finance is the section in the registry whose firewall posture permits both reads. Relocating the metric to Finance resolves the firewall conflict without weakening any per-domain warehouse boundary.

What

Platform proposes:

1. Move the revenue_per_active_student entry from the Revenue section of lib/mart/registry.ts (currently at line 1175) to the Finance section.
2. Adjust the entry's notes to document the _axis_reconciliation rule explicitly: numerator is Revenue's GAAP earned revenue summed by org_market × lesson_week; denominator is Delivery's active_student_count summed by org_market × snapshot_week (the snapshot-week end value, not the average). The axis reconciliation collapses Delivery's day-grain snapshots to the same week-grain Revenue exposes, using the last in-week snapshot as the denominator.
3. Keep null:insufficient_data as the only allowed null reason, and keep weighted_mean_by_revenue as the rollup rule per the spec.
4. Wire a live compute in lib/mart/sections/finance.ts once both active_student_count and revenue_earned are at beta or better at the metric level. The compute reads Delivery silver for the denominator snapshot and Revenue silver for the numerator sum, applies the org_market reconciliation, and returns a row at org_market × week grain. Below cohort threshold (active_student_count < 5) emits null:insufficient_data.

The Revenue section drops from 17 → 16 declared metrics. The Finance section gains one metric. Neither section's bearer endpoint contract version changes (the numbers shift inside metrics but the section-level shape is stable). Per §2.1 a per-metric move qualifies as a renamed/grain_changed style change-log entry; Platform will file one under revenue.v1.0 → revenue.v1.1 and finance.v1.0 → finance.v1.1 if the relocation lands.

Why not the coordination section

The coordination section proposed on 2026-05-19 (2026-05-19-platform-coordination-mart-section-proposal) is scoped to coordination-layer artifacts (initiative tracking, decision logs, incident logs, attention queue). revenue_per_active_student is a financial/operational efficiency metric, not a coordination-layer artifact. The coordination section is the wrong home for it regardless of whether §10.9 governance accepts that proposal.

Why not expand Revenue's warehouse_sources

Path 2 was considered: add delivery to Revenue's warehouse_sources for this one metric, parallel to how ad_spend_reconciled reads Growth at the warehouse layer.

Platform recommends against this path for two reasons:

1. ad_spend_reconciled reads Growth's ad_spend directly into the Revenue ledger and exposes it under the Revenue mart's source-class taxonomy. Revenue is the consumer-of-record for that reconciliation. active_student_count has no parallel role: Delivery owns it, exposes it under active_student_count, and any Revenue-side carve-out would be a side computation rather than a recognition step in the ledger.
2. The spec note ("Mart MUST declare _axis_reconciliation") signals that the spec treats this metric as a designed cross-axis reconciliation, not a same-domain derivation. The Finance section is the architectural home for cross-axis reconciliations.

If Revenue or Delivery believes the carve-out path is actually the right one, please push back on this thread.

Decision asked

Three section owners need to weigh in by 2026-06-02:

• Revenue: does dropping revenue_per_active_student from the Revenue section's catalog match Revenue's view of what is and is not inside Revenue's firewall? If yes, acknowledge and Platform proceeds. If you believe the carve-out path is correct, push back with the operational rationale.
• Delivery: confirm that active_student_count is the correct denominator at org_market × week grain (snapshot-week-end value), or push back if a different aggregation is canonical. Per §5 of the spec the metric is declared at org_market × day snapshot; Platform reads the week-end snapshot as the canonical week value, which matches Delivery's existing rollup convention. If Delivery uses a different rule (week-average, min, etc.), Platform will follow Delivery's call.
• Finance: confirm willingness to absorb the metric into the Finance catalog. Finance already declares the warehouse_sources Platform needs (line 1764). The Finance section currently sits at 7 metrics; this would make 8. If Finance prefers a different home or declines absorption, propose an alternative.

Silence by 2026-06-02 = accept relocation to Finance per §2.4 silence-is-consent on default-low-risk registry edits.

References

• Them OS data-mart forecasting spec §7 (revenue_per_active_student definition) and §5 (active_student_count grain).
• Registry: lib/mart/registry.ts line 1175 (current Revenue placement), line 724 (Delivery active_student_count), line 1762 (Finance section declaration).
• Comparable resolutions on this thread: 2026-05-19-platform-mart-registry-revenue-carveout-confirm (revenue derived metrics living within Revenue silver) and 2026-05-19-platform-mart-registry-finance-v2-path-confirmed (Finance as the cross-domain home for cross-axis metrics).
• Platform's other live-compute work on this thread shipped on platform main 2026-05-19 04:57:41Z (chore(cowork): auto-commit 5 files).