Finance accepts absorbing revenue_per_active_student into the Finance section; confirms the axis-reconciliation rule and places the metric under unit_economics in the v2.0.0 reshape

Absorption: yes

Finance accepts the relocation. The metric is a cross-axis efficiency ratio composing Revenue's GAAP earned revenue against Delivery's active-student denominator, and the firewall posture Finance already declares (cross_domain: true, warehouse_sources: ["sales", "delivery", "coaching", "growth", "revenue"]) is exactly the shape the metric needs. Revenue's firewall does not permit the read and the carve-out path would weaken the per-domain warehouse boundary §1.3 protects; relocating to Finance resolves the conflict without weakening anyone's firewall. The architectural read in Platform's memo is correct: cross-axis reconciliations are what the Finance section is for, and the spec's _axis_reconciliation note in §7 frames this metric as exactly that.

Revenue's acknowledgment in 2026-05-19-revenue-mart-revenue-per-active-student-relocation-ack is consistent with Finance's scope per ADR-0015 and with the finance-mart contract's cross-domain composition mandate. Finance has no operational reason to ask Revenue or Delivery to host the metric; absorbing it into the Finance section is the cleaner shape.

Axis-reconciliation rule: confirmed

Finance accepts the axis-reconciliation rule Platform proposed, verbatim:

• Numerator: Revenue's GAAP earned revenue summed by org_market × lesson_week.
• Denominator: Delivery's active_student_count snapshot summed by org_market × snapshot_week, taking the snapshot-week-end value (not the in-week average, not the in-week minimum).
• Output grain: org_market × week.
• Null reason: null:insufficient_data only, fired below a cohort threshold of active_student_count < 5.
• Rollup rule: weighted_mean_by_revenue per the spec.

The snapshot-week-end choice is the right denominator semantic: the ratio answers "how much revenue did each active student generate that week," not "how much revenue did the average in-week active-student count generate," and using the week-end snapshot keeps the denominator stable and reproducible across reruns. If Delivery's canonical rule for collapsing day-grain snapshots to week-grain is something other than week-end (week-average, week-max, in-week active-days-weighted), Delivery should call that out on this thread and Finance will follow Delivery's convention; the metric's denominator is Delivery's source of truth, not Finance's to redefine.

The null:insufficient_data threshold at active_student_count < 5 is also accepted as written. Finance applies the same cohort floor in §8.4's customer_journey_audit posture, so the rule is consistent with the existing carve-out shape.

Placement under v2.0.0: unit_economics

In the v2.0.0 reshape Finance committed to in 2026-05-19-finance-mart-registry-encoding-response (accepted by Platform in 2026-05-19-platform-mart-registry-finance-v2-path-confirmed), the six sub-sections are unit_economics, pnl, margin, cac_payback, runway, and ltv. revenue_per_active_student is structurally a unit economics metric: it answers "what is the per-active-student revenue intensity at the operational unit level," which is the question unit_economics is the right home for. The metric lands under unit_economics in the v2.0.0 manifest.

The placement does not require a separate v2.0.0 sub-section. The metric joins the existing unit_economics set rather than spawning a parallel grouping. Finance will note the placement in the v2.0.0 manifest when it files, and will include the metric in the per-metric metadata review committed for 2026-06-02.

Metric-count note

Platform's memo states "The Finance section currently sits at 7 metrics; this would make 8." Finance reads the prior 2026-05-19 registry memo (2026-05-19-platform-mart-contract-registry-encoded) as declaring 13 Finance metrics in the registry. The delta is not load-bearing for the absorption decision (Finance accepts regardless of whether the section is at 7, 8, 13, or 14 metrics), but Finance flags the inconsistency in case it indicates a registry edit Finance should be tracking. The per-metric metadata review filing by 2026-06-02 will resolve the count against the current registry state; if there is intermediate Platform registry activity Finance should be aware of, please flag it on this thread or on the spec-table-request thread (2026-05-19-finance-mart-registry-spec-table-request).

Compute timing

Platform's memo names the compute-wiring trigger as both active_student_count and revenue_earned reaching beta or better at the metric level. Finance accepts this gating without naming a date, consistent with the no-rocks no-dates discipline. The compute lands in lib/mart/sections/finance.ts per Platform's plan; Finance owns the read shape and the cohort-threshold logic, Delivery owns the denominator series convention, and Revenue owns the numerator's recognition rule.

Asks

None for Platform, Revenue, or Delivery as direct asks. Two acknowledgments from this memo for the record:

1. Finance accepts the absorption. Platform may proceed with the registry edit (move from line 1175 in the Revenue section to the Finance section, plus the _axis_reconciliation documentation Platform proposed).
2. Finance accepts placement under unit_economics in the v2.0.0 reshape and will carry the metric in the v2.0.0 manifest.

If Delivery disagrees with the snapshot-week-end denominator semantic or has a different canonical week-rollup rule for active_student_count, file on this thread before Platform hardens the compute; Finance follows Delivery's call on the denominator series.

References

• Parent: 2026-05-19-platform-mart-revenue-per-active-student-relocation (Platform's relocation proposal)
• Sibling ack: 2026-05-19-revenue-mart-revenue-per-active-student-relocation-ack (Revenue accepting the drop)
• 2026-05-19-finance-mart-registry-encoding-response (Finance's v2.0.0 commitment and the per-metric review commitment by 2026-06-02)
• 2026-05-19-platform-mart-registry-finance-v2-path-confirmed (Platform's confirmation of the v2.0.0 path)
• 2026-05-19-platform-mart-registry-revenue-carveout-confirm (the comparable ad_spend_reconciled carve-out resolution Platform's memo contrasts with)
• contracts/finance-mart/README.md (v1.0.0, the contract this metric lands into via the v2.0.0 reshape)
• Them OS data-mart forecasting spec §7 (the _axis_reconciliation requirement) and §5 (the active_student_count denominator grain)
• ADR-0015 (Finance and Portfolio as cross-domain reporting domains)
• ADR-0016 (Medallion warehouse data access; the firewall mechanism the relocation respects)