Portfolio access pattern response: reporting scope, join patterns, and test data posture
Reporting scope
Portfolio's intended reporting scope was filed in full in 2026-05-14-portfolio-mart-contract-publication, including the three analytics questions the gold section is built to answer: cross-Market performance, cross-discipline performance, and portfolio-level funnel health. That memo also enumerates the three metric families and their dimensional keys (Market, Service Area, Organization, time period, funnel stage). No additional scope is in flight; the three families in contracts/portfolio-mart/ §4.3 are the complete planned surface.
The entities Portfolio needs to join: Person (via the spine), Organization (discipline boundary, via the spine), Market and Service Area (via the spine), plus the operational facts from each of the five silver faces — lead counts and lead-to-opportunity conversion from growth, opportunity and enrollment counts from sales, lesson counts and completion status from delivery, coaching session and coach-to-swimmer assignment facts from coaching, and earned-revenue figures from revenue. The portfolio gold section does not touch bronze.
Cross-domain join patterns
Portfolio joins all five silver faces and the spine. The spine's person_id is the correct and sufficient cross-domain join key for Portfolio's use; Portfolio does not anticipate any join Pattern that bypasses it. The specific cross-discipline dedup case (ADR-0014: a Person active in two Organizations should count once in the portfolio-level rollup) is handled at the gold section level using person_id as the dedup key across Organization-scoped aggregations. Portfolio does not need a different or broader join key to do that dedup correctly.
The one surface Portfolio is still waiting on Platform to confirm is that the planned silver faces will carry the funnel-stage, cross-Market performance, and cross-discipline performance columns that the portfolio-mart families compose from — this was the first ask in 2026-05-14-portfolio-mart-contract-publication and remains open. Portfolio is not raising a new surface gap here; it is restating the existing confirmation request so Platform can hold both threads together as it validates silver coverage.
Test data posture
Portfolio expects hard-filtering of test records at the silver layer, not passthrough. Portfolio is a cross-domain aggregate reporting domain; any test records that reach the portfolio gold section will corrupt the strategy metrics — inflated funnel counts, distorted Market and discipline performance, noise in the cross-discipline dedup. Portfolio cannot reliably filter test records in its own gold section logic because the definition of what constitutes a test record is bronze-layer knowledge, owned by each operational domain. Pushing that filter into the gold section would force Portfolio to absorb per-domain knowledge it does not own, which defeats the point of the conform layer.
Portfolio's position: the silver faces should hard-filter rows flagged as test records before they reach any consumer. If the current silver spec is undecided on this, Portfolio is registering a preference now so Platform can factor it into the face spec and the per-face column manifests. Portfolio is not asking for a contract amendment; it is asking Platform to confirm the decision before the manifests ship.
References
2026-05-14-portfolio-mart-contract-publication(reporting scope, join pattern detail, firewall bound request)contracts/portfolio-mart/README.md(v1.0.0)contracts/warehouse-silver/README.md(v1.0.0)- ADR-0015 (Portfolio as a cross-domain reporting domain)
- ADR-0016 (Medallion warehouse layout)
- ADR-0014 (each discipline as its own Organization; cross-discipline dedup rule)
- ADR-0003 (Person canonical entity;
person_idas cross-domain join key)