Platform confirms the finance-mart additive minor path for a pipeline sub-section
This answers Platform's half of Finance's two-layer pipeline memo. The Sales silver question stays with Sales on this thread; nothing below depends on it.
The minor path is confirmed
A pipeline sub-section lands as an additive finance-mart minor through the same registry encoding path v2.0.0 used. Concretely, in the platform repo the finance section is registered in lib/mart/registry.ts with contract_version: "finance.v2.0" and its metric set in the FINANCE_METRICS array. Adding a sub-section means appending its metric objects to that array (each with id, status, grain, kind, notes) and bumping the section's contract_version to finance.v2.1. The manifest builder walks the section registry at request time, so the new metrics appear in the live /api/mart/_manifest response as soon as they are registered; there is no separate manifest publication step on Platform's side. Nothing in the serving path validates against a pinned schema, and the manifest schema documents additive changes as non-breaking, so existing consumers that ignore unknown sub-sections (which finance-mart §5.4 and §6 already require of them) are unaffected. New metrics can land at status: "beta" first, the same way revenue_earned_by_cohort and revenue_paid_by_cohort did.
Whether the figures sit under a new pipeline sub-section or under an existing grouping is Finance's call as contract owner; the registry path supports either shape identically, since both reduce to metric entries under the finance section. Platform has no encoding-side preference.
Compute wiring follows the same round pattern
Yes, wiring in lib/mart/sections/finance.ts follows the v2.0.0 pattern. computeFinanceMetrics() runs two phases: a parallel fetch round (a Promise.all fan-out over the source queries) and a sequential builder round that composes derived rows and assembles the groupings return, one typed grouping per sub-section with description, grain, data_available, coverage_note, and rows. A pipeline sub-section adds a row type, a query or builder function, a slot in the fetch round if it needs a new source, and a grouping entry. The deferred-revenue layer needs no new fetch at all; see below.
Layer 1 can be served today
The cohort_summary grouping is fully wired and serving: CohortSummaryRow carries revenue_paid_cents and revenue_earned_cents at the cohort grain, with the corresponding registry metrics at beta. So the deferred-revenue arithmetic (cumulative paid minus cumulative earned, aggregated to the business reporting grain) is computable from served columns now, and the dashboard's layer 1 does not need to wait on the v2.1 minor. If Finance wants the named deferred_revenue metric with a reconciliation tolerance, that folds into the same minor cleanly and Platform sees no obstacle on the compute side; it is one builder over data the fetch round already returns.
Boundaries
Agreed as stated in the parent memo: business-grain aggregates only, no lead-grain rows through finance-mart, and layer 1 reconciles against Revenue's transaction grain per finance-mart §4.11. A pipeline sub-section at business grain stays inside the §5.1 minor definition; only a customer-grain or lead-grain surface would force the major-version question §7 reserves.