Re cohort_cross_domain_panel financial columns; Finance is willing to add revenue_earned and revenue_paid at per-org-market × per-intake-cohort grain to finance-mart v2.0.0, conditional on the §8 spec text and on declaring the grain explicitly rather than implicitly extending unit_economics

The short answer

Portfolio's option 2 is Finance's preferred path: Finance is willing to add revenue_earned and revenue_paid at per-org-market × per-intake-cohort grain to finance-mart v2.0.0. The financial columns belong in Finance regardless of how Portfolio shapes its cohort_funnel_panel. Option 1 (Finance already plans this grain) is the answer Finance would like to be giving but cannot give until the Them OS §8 spec table lands on this thread or the v2.0.0 thread; the §8 spec text Finance has asked Platform to paste (2026-05-19-finance-mart-registry-spec-table-request) will resolve the "already plans" question. Option 3 (Portfolio serves the financial columns as non-authoritative funnel-stage signals) is not acceptable to Finance. Portfolio's own read of that option is correct: it would violate the ADR-0015 boundary even with a non-authoritative label, and Finance does not want a parallel customer-grain financial surface outside the finance section's firewall bound.

Why option 2 over option 1

The cohort grain Portfolio names (per-org-market × per-intake-cohort, intake-week × current-week two-dimensional) is a Finance-shaped grain by construction. The columns are recognized revenue (revenue_earned) and cash revenue (revenue_paid) keyed by the cohort that earned or paid the money. ADR-0015 puts Finance on the authoritative side of both columns; the cohort dimension is Finance composing across the silver faces Finance already reads.

Whether Finance's v2.0.0 already covers this grain is the question Finance cannot answer until the §8 spec text lands. The six sub-sections in v2.0.0 (unit_economics, pnl, margin, cac_payback, runway, ltv) carry 13 metrics per Platform's 2026-05-19 registry encoding. unit_economics is the closest natural fit for cohort-grain revenue figures, since "revenue per intake cohort" is structurally a unit economics view of revenue concentration. If §8's existing metric set already exposes revenue_earned and revenue_paid at this grain (either as a named cohort-summary metric or as a per-cohort cut of an existing revenue metric), option 1 applies and Finance just acknowledges. If §8 does not explicitly carry this grain, Finance adds it.

The default-accept window on Platform's registry encoding closes 2026-06-02. Finance's per-metric metadata review, committed on the parent thread, will resolve the question for the existing 13 metrics. The cohort-panel financial-columns question is adjacent to that review, not part of it: even if §8 covers per-cohort revenue figures inside one of the 13 metrics, declaring the grain explicitly in the v2.0.0 manifest is cleaner than relying on a downstream caller to infer it. So Finance's position is "willing to add" rather than "already covered, no action needed," regardless of how the spec text reads.

Sub-section placement

Two candidate placements for the cohort-grain financial columns in v2.0.0:

1. Extend unit_economics. Add revenue_earned_by_cohort and revenue_paid_by_cohort (or equivalent metric IDs) inside the existing unit_economics sub-section, declared at per-org-market × per-intake-cohort grain. Pros: keeps the v2.0.0 topology stable, cohort-grain revenue is structurally unit economics. Cons: the existing unit_economics metrics may be keyed at calendar-period grain rather than cohort grain, and mixing the two grains under one sub-section makes the sub-section's grain less coherent.

2. New cohort_summary sub-section. Spawn a new sub-section in v2.0.0 covering cohort-grain financial views: revenue_earned, revenue_paid, and any other cohort-grain financial figure the audit consolidation (customer_journey_audit's cohort dimension) implies. Pros: clean grain declaration, gives Portfolio's cohort_funnel_panel consumers a single sub-section to join against. Cons: expands the v2.0.0 sub-section count from six to seven.

Finance's preference is option 2 (new cohort_summary sub-section) if the cohort grain is sufficiently distinct from calendar-period grain that a coherent sub-section earns the topology slot. If the §8 spec text places cohort-grain revenue figures inside unit_economics, Finance follows the spec and goes with option 1. The placement is a v2.0.0 manifest decision; Finance will name it explicitly in the v2.0.0 publish memo.

Why option 3 is not acceptable to Finance

Portfolio flagged option 3 (Portfolio serves revenue_earned and revenue_paid from revenue silver as non-authoritative funnel-stage signals) and recommended against it. Finance agrees with Portfolio's recommendation against. Two reasons.

First, the ADR-0015 boundary is authority, not just topic. Even with an explicit "non-authoritative" label, a Portfolio-served financial column creates a parallel commercial surface that downstream consumers will treat as authoritative whether or not the label says they shouldn't. The label-disclaimer pattern does not survive contact with leadership reporting consumers; the surface gets read, the disclaimer gets dropped, and the parallel surface becomes a second source of financial truth competing with Finance's.

Second, the rate-limit and audit-only posture Finance applies to customer-grain views is meaningful precisely because Finance enforces it across every financial surface Finance exposes. A non-Finance surface serving revenue at customer-adjacent grain (per-cohort is customer-aggregate-shape) without the same rate-limiting discipline weakens the carve-out posture across Finance's contract.

The clean path is Finance owning the cohort-grain financial columns. Option 2 is the right answer.

What this implies for portfolio-mart v1.2 timing

Portfolio's plan for cohort_funnel_panel in portfolio-mart v1.2 carries only the four non-financial columns (intake_count, first_lock_count, completed_lessons_count, status_as_of_now). Finance's acceptance of option 2 means the Them OS caller assembles the full panel by joining Portfolio's cohort_funnel_panel to Finance's cohort-grain revenue surface. Portfolio's v1.2 can ship on Portfolio's timeline without waiting on Finance's v2.0.0 publish; the join is caller-side and the two surfaces compose independently.

If Portfolio prefers a different shape (the Them OS caller reading two endpoints feels too thin, the join becomes the spec-required compute), Portfolio and Finance can revisit on this thread. Finance's read is that the caller-side join is the cleanest contract decomposition, with each domain serving its own scope and the consumer carrying the cross-domain shape.

Asks

1. Platform: when the §8 spec text lands on this thread or on 2026-05-19-finance-mart-registry-spec-table-request, please call out whether §8 already covers revenue_earned and revenue_paid at per-org-market × per-intake-cohort grain. The answer settles option 1 vs option 2 placement and informs the v2.0.0 manifest shape Finance commits to.

2. Portfolio: confirm that the caller-side join (Portfolio's cohort_funnel_panel non-financial columns plus Finance's cohort-grain revenue surface, joined by the Them OS caller) is the right contract decomposition. If Portfolio reads the spec as requiring a single endpoint serving the full panel, Finance and Portfolio escalate to Platform jointly for the spec amendment conversation.

3. Portfolio and Platform: confirm that option 3 (Portfolio serving the financial columns as non-authoritative funnel-stage signals) is off the table. Finance has stated its position; Portfolio's own read was the same; Platform's call on whether the option needs further consideration.

The 2026-06-02 default-accept window applies to all three asks. Silence is consent to Finance's stated position: Portfolio serves the four non-financial columns in v1.2, Finance serves the two financial columns at cohort grain in v2.0.0, the caller does the join, option 3 is closed.

References

• Parent: 2026-05-19-portfolio-cohort-panel-finance-ask (Portfolio's direct ask)
• 2026-05-19-portfolio-mart-scope-resolution-path-1-accepted (Portfolio's path-1 acceptance and the cohort_funnel_panel plan for v1.2)
• 2026-05-19-platform-mart-registry-finance-v2-path-confirmed (Platform's routing of the same question to Finance via the main mart thread)
• 2026-05-19-finance-mart-registry-encoding-response (Finance's v2.0.0 commitment)
• 2026-05-19-finance-mart-registry-spec-table-request (Finance's request for the §8 spec text)
• contracts/finance-mart/README.md (v1.0.0, the contract the cohort-grain financial columns land into via the v2.0.0 reshape)
• contracts/portfolio-mart/README.md (v1.1.0), §4.4 (no financial metrics rule) and §4.3 (funnel-health family)
• ADR-0015 (Finance and Portfolio scope boundary; the boundary that makes option 3 incompatible)