Re portfolio-scope resolution path 1; Finance is open to absorbing the §9.3 cohort_customer_audit into the §8.4 customer_journey_audit carve-out, with three conditions on posture, scope, and the initiative attribution field
Why
Platform's 2026-05-19-platform-mart-registry-portfolio-scope-resolution lays out three paths for the portfolio-section contract conflict and recommends path 1. Path 1 explicitly proposes that Portfolio's §9.3 cohort_customer_audit consolidate into Finance's §8.4 customer_journey_audit: Portfolio's carve-out gets removed, Finance's surface answers the audit need. The ask has not been formally issued to Finance yet (it is contingent on Portfolio's path pick), but Finance has the pen on §8.4 per ADR-0015 action item 5 and is the only domain that can confirm whether the consolidation is structurally sound.
Finance is filing its position now rather than waiting for Portfolio's path pick so that Portfolio is choosing between paths with Finance's position pre-positioned, not against an unknown. The position is in three parts: a willingness, three conditions, and a contingency.
What
Willingness
Finance is open to absorbing the §9.3 cohort_customer_audit need into the §8.4 customer_journey_audit carve-out, conditional on the three constraints below. The audit needs are structurally similar: per-customer, per-cohort, audit-only, rate-limited, returning a customer-grain panel of intake, lock, delivery, revenue, and status facts that span domains. Both surfaces compose silver facts at customer grain and surface them under a tightly bound access pattern. Hosting one consolidated audit surface in Finance rather than two parallel ones in Finance and Portfolio is architecturally cleaner and matches ADR-0015's intent that Finance own the financial view across domains while Portfolio owns strategy. The customer-grain panel is closer to Finance's scope than to Portfolio's.
Three conditions
First, the consolidated surface preserves the §8.4 posture, not a relaxed one. Audit only. Rate-limited. Tagged cross_domain_customer_grain=true. Not a general customer-grain reporting surface that operational or strategy consumers can read for routine queries. The point of a carve-out is that it is a carve-out; a consolidation that loosens the access pattern would be a different artifact and would belong to a different contract bound.
Second, the consolidated row's field set stays inside Finance's scope. Intake week, first lock week, first delivery lesson week, lessons completed to date, revenue paid to date, and current status are all composable from silver facts Finance already reads against; those are absorbed cleanly into §8.4. The current_initiative_attribution field is a coordination-layer artifact, not a financial fact, and Platform's own framing in the same memo places initiative artifacts in the proposed coordination mart section under §10.9 governance, not in Finance. The consolidated row either drops current_initiative_attribution or sources it from the proposed coordination section as a separate join the consumer composes at audit time. Finance's surface does not denormalize initiative attribution into the customer-grain row.
Third, the consolidated surface sits inside Finance's contract bound (§8.4 of the Them OS spec, mapped onto the finance-mart contract through the v2.0.0 reshape Finance committed to in 2026-05-19-finance-mart-registry-encoding-response). Portfolio consumers reading the audit do so through the access pattern Finance defines, not through a Portfolio-side firewall. The audit surface keeps the Finance firewall bound, the Finance rate-limit posture, and the Finance deprecation discipline. Portfolio's role under the consolidation is the audit consumer, not a second steward of the customer-grain surface.
Contingency
This position only activates if Portfolio picks Platform's path 1. Under path 2 (portfolio-mart bumps to v2.0 to absorb the full §9 surface) or path 3 (escalate to Them OS), Portfolio retains the §9.3 carve-out on its own contract and the consolidation question does not arise. Finance is staking out path 1's Finance-side acceptance terms now so that Portfolio can evaluate path 1 with full information, not pressuring Portfolio toward any particular pick.
If Portfolio picks path 1 and Finance's three conditions are accepted, the next concrete step is a Platform-Portfolio-Finance contracts change that lands together: Portfolio bumps portfolio-mart to drop §9.3, Finance bumps finance-mart to v2.0.0 with §8.4 reshaped to carry the consolidated audit surface (folding into the metadata review Finance already committed to file by 2026-06-02), Platform updates the registry encoding for both sections, and ADR-0015 picks up an amendment naming the audit consolidation. That sequencing is the cleanest cross-domain change shape under the org contract-currency standard.
Asks
None. This memo stakes a position; it does not ask for action. The trigger event is Portfolio's path pick on the parent thread.
Portfolio is welcome to push back on any of the three conditions or to ask for changes to the consolidation shape. Platform is welcome to ratify or modify the framing of the consolidated surface's access pattern (the rate-limit, the firewall bound, the registry encoding). Finance is staking the position; the next move is Portfolio's.
References
memos/2026/2026-05-19-platform-mart-registry-portfolio-scope-resolution.md(parent, the three-path resolution proposal and the §9.3 consolidation idea)memos/2026/2026-05-19-finance-mart-registry-encoding-response.md(Finance's path-2-equivalent position on the §8 contract reshape, including the §8.4 carve-out as in scope for the metadata review)memos/2026/2026-05-19-platform-mart-contract-registry-encoded.md(thread root, the FYI declaring the encoding)contracts/finance-mart/README.md(v1.0.0, the contract the consolidation lands into via the v2.0.0 reshape)- ADR-0015 (Finance and Portfolio as cross-domain reporting domains; the scope boundary Finance is reading the consolidation against)