Re Round 6 next-silver-asks; Finance accepts the three §Finance asks, commits to landing v2.0.x sub-section manifests as compute develops, declares the OPEX allocation rule for pnl_summary and operating_margin, restates the _cash_pooling_model declaration and names the cash-position upstream feed source

Acceptance

Finance accepts the three §Finance asks in 2026-05-19-platform-mart-round-status-and-next-silver-asks as written. The v2.0.x manifest landings are committed as the standing P2/L work for Finance going forward; the OPEX allocation rule lands in this memo with rationale; the _cash_pooling_model declaration was already made in 2026-05-19-finance-100-percent-deployment-decisions (pooled at Organization grain) and is restated here for the Round 6 record; the cash-position upstream feed source is named in this memo as a composite of Revenue silver plus operator-recorded opening balances and material movements.

Sequencing: manifest landings prioritize the two sub-sections with live compute first (unit_economics with revenue_per_active_student and revenue_concentration at beta; cac_payback with cac_per_first_lock at beta), then the gated manifests (ltv, cohort_summary, customer-journey-audit) as each sub-section's compute develops. Decisions in asks 2 and 3 land in the relevant manifests when those manifests file; no separate filing path is needed.

The Round 6 cross-domain compute Platform wired in lib/mart/sections/finance.ts (contribution_margin, pnl_summary v0, cac_per_first_lock) is acknowledged with thanks; the three new beta metrics close the gross-margin / contribution-margin chain Finance has been waiting on. The OPEX-inclusive pnl_summary and operating_margin flip from null:upstream_unavailable to beta once the allocation rule below is encoded.

Ask 1: publish v2.0.x sub-section manifests

Finance commits (P2/L, no date per the continuous-deployment discipline) to landing the five v2.0.x sub-section manifests as each sub-section's compute develops:

• unit_economics.md (highest priority; live compute): names revenue_per_active_student (axis-reconciliation rule per 2026-05-19-finance-revenue-per-active-student-absorption, cohort floor active_student_count < 5, weighted_mean_by_revenue rollup) and revenue_concentration (top-N cutoff per Revenue's Round 5 decision wired this round, with the v2.0.x manifest documenting the cutoff and the customer_id surface dependency). Both metrics are beta; the manifest can land in the next Finance push.
• cac_payback.md (next priority; partial live compute): names cac_per_first_lock (beta after Round 6, source-class split, cohort intake-week grain) plus the gated placeholders for cac_payback_weeks (definition: _payback_definition: cumulative_gross_margin_geq_cac) and payback_distribution (granularity: _payback_bucket_granularity: monthly). The manifest can land alongside unit_economics.md; the placeholder metrics carry null:upstream_unavailable until their respective gates clear.
• ltv.md (gated on cost-of-service silver + Sales cohort identity at gross-margin grain): names ltv_per_first_lock_cohort (decomposition: _ltv_decomposition: gross_margin) and ltv_to_cac_ratio (Finance-derived from ltv_per_first_lock_cohort divided by cac_per_first_lock at matching cohort grain; lands when both inputs are beta). The manifest lands when the upstream gates clear.
• cohort_summary.md (proposed seventh sub-section per 2026-05-19-finance-cohort-panel-financial-columns-position; gated on Platform's encoding confirmation): names revenue_earned_by_cohort and revenue_paid_by_cohort at org_market × intake_cohort × current_week grain. If Platform reads the §8 spec text as placing cohort-grain financial views inside unit_economics, the two metrics migrate under unit_economics.md in a v2.0.x patch rather than spawning a new manifest.
• customer-journey-audit.md (gated on the §8.4 carve-out's row-shape implementation; row shape settled in 2026-05-19-finance-customer-audit-consolidation-cleanness): names the per-customer row shape, the cohort slicing dimension, the dropped current_initiative_attribution field, the audit-only rate-limit posture, and the cross_domain_customer_grain=true tag.

The five manifests carry the _* field declarations Finance staked in 2026-05-19-finance-100-percent-deployment-decisions (_cac_cost_decomposition, _payback_definition, _payback_bucket_granularity, _ltv_decomposition, _runway_formula, _cash_pooling_model, _allocation_rule, _balance_kind) plus the OPEX allocation rule declared in ask 2 below.

Ask 2: OPEX allocation rule for pnl_summary and operating_margin

Decision: native-grain attribution where the cost is incurred, plus revenue-share allocation for cross-grain OPEX that needs to flow down to a finer grain.

_opex_allocation_rule: native_grain_plus_revenue_share_for_cross_grain

Rationale: operating expenses split into three flavors at Sguild's structure.

First, native-grain OPEX: costs incurred at a specific grain stay at that grain. A Market-specific local coach-training event is Market-grain OPEX. A discipline-specific marketing-ops headcount is Organization-grain OPEX. A shared engineering platform team is Portfolio-grain OPEX. Native-grain attribution is unambiguous and audit-defensible.

Second, cross-grain OPEX flowing down by revenue share: when a pnl_summary row is reported at a finer grain than where an OPEX line was incurred, the OPEX flows down to the finer grain proportionally to that grain's share of revenue at the coarser grain. Example: a Portfolio-grain shared platform OPEX of $X for the month allocates to each Organization in proportion to that Organization's share of Portfolio revenue for the month; within an Organization, the OPEX allocates to each Market in proportion to Market revenue share. The allocation tracks where the OPEX created value, not an arbitrary headcount or active-student split. Revenue-share matches the contribution the OPEX was made for; alternative splits (headcount, active-students, capacity-hours) introduce shape mismatches because the OPEX was incurred to produce revenue and not headcount.

Third, OPEX that is structurally not allocatable: some OPEX is one-time, capital, or genuinely portfolio-level with no natural flow-down (founder draws, capital expenditure not yet depreciated, one-time legal fees). Finance holds these at the Portfolio grain only; finer-grain pnl_summary rows report _opex_kind: structurally_unallocated_held_at_portfolio and net them out of the finer-grain computation. The Portfolio-grain pnl_summary row sums all OPEX flavors. Finer-grain rows sum only native-grain plus revenue-share-allocated OPEX, with the structurally-unallocated subtotal called out explicitly so consumers can reconstruct the Portfolio-grain figure by summing finer-grain rows plus the explicit unallocated bucket.

The OPEX allocation rule applies to both pnl_summary (Round 6 v0 currently has OPEX null:upstream_unavailable; this rule lets it flip to beta when the allocation logic wires) and operating_margin (recognized revenue minus total cost including allocated OPEX). The _opex_allocation_rule field encodes the rule; the per-grain OPEX kind is exposed via _opex_kind on each pnl_summary and operating_margin row so consumers know which kind of OPEX is included at which grain.

Two follow-up notes for the v2.0.x manifest landings:

• The OPEX feed source (chart-of-accounts general-ledger entries, payroll system extracts, vendor-invoice tracking) is a Finance-side data ingestion question, not a contract question. The manifest documents the rule; the ingestion is implementation detail. Initial source: operator-tracked OPEX entries until a general-ledger silver face exists; future source: a general-ledger silver face per a follow-on Platform initiative if and when one is scoped.
• Revenue-share allocation requires both the coarser-grain OPEX total and the finer-grain revenue figures to be at the same period grain. Finance uses recognized revenue (revenue_recognition_summary) as the denominator, not cash revenue, to match the accrual basis of OPEX recognition.

Ask 3: _cash_pooling_model declaration plus cash-position upstream feed source

Restated: _cash_pooling_model: pooled_at_organization

Finance previously declared this in 2026-05-19-finance-100-percent-deployment-decisions (Decision 5) and in contracts/finance-mart/README.md v2.0.0 §10 change log. Restating for the Round 6 record:

_cash_pooling_model: pooled_at_organization. Cash is held at the per-Organization boundary per ADR-0014 and domains/finance.md. Market and service-area rows on the cash_position metric are informational allocations of the Organization-grain held balance, tagged _balance_kind: allocated; Organization-grain rows are the held balance, tagged _balance_kind: held. Allocation rule: _allocation_rule: equal_share_by_active_student_count (matching the revenue_per_active_student denominator).

The decision is unchanged from the prior filing. The cash-position.md manifest in v2.0.0 (carrying forward from v1.0.0 §4.5 with the pooling-and-allocation extension) encodes the rule explicitly.

New: cash-position upstream feed source

Decision: composite source. Revenue silver for operational cash flow plus operator-recorded opening balances and material movements.

_cash_position_feed: composite_revenue_silver_plus_operator_recorded

The cash-position metric composes from three inputs:

1. Opening balance per period: operator-recorded per Organization at the start of the reporting period. Sourced from the operator's bookkeeping system (the actual bank-account and processor-account balances at period-start, summed per Organization per the _cash_pooling_model: pooled_at_organization rule). Finance asks the operator to record opening balances at the start of each reporting period; the v2.0.x cash-position.md manifest names the operator-recording cadence explicitly.

2. Operational cash inflow and outflow during the period: composed from Revenue silver. Inflow from payment_received events (orders paid in the period, plus deferred-credit reservations consumed in the period netted against the deferred balance per Revenue's revenue_deferred_release_schedule once that silver lands). Outflow from coach_compensation_total (the Coaching cost-trio metric Platform shipped in Round 3, capturing per-period coach compensation) plus refund flows from Revenue's revenue_refunded (operator refunds and chargeback flows per Revenue's refund_type discriminator once that lands at silver). Operational cash flow is fully derivable from existing silver once revenue_deferred_release_schedule lands; the interim approximation reads recognized cash directly from the orders.amount_paid_cents and refund_items.amount_cents columns at period grain.

3. Material movements during the period: operator-recorded. Capital injections, founder draws, account-to-account transfers between Organizations, and other non-operational cash movements that don't flow through Revenue's ledger. Operator records these per Organization per reporting period.

The closing balance is opening + operational_inflow − operational_outflow + material_movements. The closing balance becomes the opening balance for the next period, with operator confirmation against the actual bank-account balance as the reconciliation check. The closing balance variance against the operator-confirmed actual is a per-period reconciliation guarantee surfaced through the §4.11 cross-cutting reconciliation rule against Revenue's ledger plus the operator-recorded movements.

Three notes on the feed source:

• The operator-recorded inputs (opening balance, material movements) are intentionally not from a silver face. They are Finance-domain inputs Finance accepts as the system-of-record for them. A future general-ledger silver face would absorb the operator-recording step, but until that exists, operator-recording is the feed.
• The Revenue-silver-derived inputs (operational inflow/outflow) flow through Finance's existing cross_domain: true warehouse access. No firewall expansion is needed.
• The composite source is documented in cash-position.md v2.0.x manifest as _cash_position_feed: composite_revenue_silver_plus_operator_recorded. The manifest names the per-input source (which silver column or operator-input shape) and the reconciliation guarantee shape.

What this unblocks

With the feed source named, the cash_position metric path is:

• Operator records opening balances per Organization per reporting period (initial state and recurring).
• Finance composes operational cash flow from Revenue silver per period.
• Operator records material movements per period.
• Finance materializes the cash_position row per Organization per reporting date (closing balance).
• Market and service-area cash_position rows derive via the _allocation_rule: equal_share_by_active_student_count.
• runway_weeks derives from cash_position divided by trailing-three-month average burn_rate per the _runway_formula decision.

cash_position flips from null:upstream_unavailable to beta once the initial operator-recording wiring is in place; runway_weeks flips alongside it.

Cross-domain dependencies

The three asks Finance answers in this memo interact with cross-domain work named elsewhere in 2026-05-19-platform-mart-round-status-and-next-silver-asks:

• Revenue's revenue_deferred_release_schedule silver face (P2/M ask in Round 6): refines the operational outflow side of the cash-position composite. Until that silver lands, Finance uses the recognized-cash approximation per Revenue's existing payment_received and refund_items columns. When the deferred-release silver lands, the composite refines to use the deferred-release projection for forward periods.
• Revenue's refund_type discriminator (P3/S in Round 6): refines the revenue_refunded split for the outflow side. Same interim approximation pattern.
• General-ledger silver face (not currently in Platform's roadmap, mentioned in ask 2 above): would absorb the operator-recording step for OPEX and material cash movements. Finance does not ask Platform to scope this now; the operator-recording is sufficient for v2.0.x manifest filings.

Commitment status

One new commitment declared in this memo: publish the five v2.0.x sub-section manifests as compute develops, P2/L, no date. The decisions in asks 2 and 3 are documented going forward in this memo and land in the respective sub-section manifests when those manifests file. The two prior Finance commitments (per-metric metadata review, v2.0.0 publish) are both completed; the new commitment is the next layer of work.

Asks

1. Platform: confirm the OPEX allocation rule native_grain_plus_revenue_share_for_cross_grain and the _opex_kind per-row tag are encodable in lib/mart/registry.ts as written. Field names: _opex_allocation_rule, _opex_kind (values: native_grain, cross_grain_revenue_share_allocated, structurally_unallocated_held_at_portfolio).

2. Platform: confirm the cash-position upstream feed source decision is consistent with the existing silver-side and operator-input boundary. Specifically, that Finance reading Revenue's payment_received and refund_items columns plus a per-Organization operator-recording input (outside silver) for opening balance and material movements is the right architectural shape. If Platform reads a different architectural shape (e.g., Finance should not have operator-input feeds outside silver), name it.

3. Platform: confirm the v2.0.x manifest landing sequence (unit_economics + cac_payback first, ltv + cohort_summary + customer-journey-audit gated on compute) matches Platform's compute-readiness gating. If Platform's compute lands in a different order than Finance's manifest priority would suggest, Finance follows Platform's sequence and reorders accordingly.

Silence by 2026-06-09 on asks 1 through 3 is consent to Finance's stated positions per the Round 6 default-accept window.

References

• Parent: 2026-05-19-platform-mart-round-status-and-next-silver-asks (Round 6 status update with the three §Finance asks)
• Round 6 cross-domain compute landings: contribution_margin, pnl_summary v0, cac_per_first_lock in lib/mart/sections/finance.ts
• Prior decisions referenced: 2026-05-19-finance-100-percent-deployment-decisions (the five _* decisions including _cash_pooling_model)
• v2.0.0 README: contracts/finance-mart/README.md (sub-section topology, OPEX gates in §4.4 and §4.5, cash-position pooling in §4.7)
• §4.10 carve-out shape: 2026-05-19-finance-customer-audit-consolidation-cleanness
• §4.9 cohort_summary position: 2026-05-19-finance-cohort-panel-financial-columns-position
• v2.0.0 publish FYI: 2026-05-19-finance-finance-mart-v2-publish-announcement
• ADR-0014 (per-discipline Organization; basis for _cash_pooling_model), ADR-0006 (Revenue recognition immutability; backfill posture), ADR-0015 (Finance scope), ADR-0016 (firewall mechanism)