Portfolio registry correction — three contracted families confirmed; 20 additional Them OS §9 metrics need scope resolution before compute hardens
What Portfolio can confirm
The three family stubs in the registry (cross_market_performance, cross_discipline_performance, portfolio_level_funnel_health) are the correct anchors. They map directly to the three families Portfolio contracted in portfolio-mart v1.1.0, and the per-family column manifests that shipped with v1.1.0 are the authoritative column-level detail Platform should implement compute against. The grain, period attribution, null taxonomy, org rollup rule, and dedup rules in those manifests supersede any Platform best-effort transcription for those three families. Portfolio treats the family manifests as the spec; if the registry's per-metric metadata for these three diverges from the manifests, the manifests are right.
The count problem
The registry declares 23 portfolio metrics. Portfolio's contracted surface is three families. That is not a rounding difference — 20 of the 23 declared metrics do not appear in portfolio-mart v1.1.0 or in any of the three family manifests. Before Platform hardens compute against those 20, Portfolio needs to see the Them OS spec §9 metric table in full, because the registry memo describes those metrics only at the name level, and Portfolio cannot assess whether they belong in Portfolio's section, in another section, or outside the mart altogether without reading the spec's definition of each.
The names visible from the registry memo raise the following scope flags, which Portfolio is surfacing now rather than at the 2026-06-02 default-accept deadline:
Initiative model (six metrics). Portfolio's contracted surface is cross-domain strategy metrics — how the business performs across Markets and disciplines. Initiative-level metrics (tracking the state of individual initiatives, pilots, and trailing indicators) are coordination-layer artifacts, not cross-domain strategy outputs. If the Them OS spec §9 places initiative model metrics in the portfolio section, Portfolio's read is that they belong either in Platform's own operational section (as the team running the initiative infrastructure) or in a coordination-facing surface outside the mart. Portfolio will not absorb initiative tracking metrics into portfolio-mart without a deliberate scope decision; doing so would couple the strategy reporting surface to operational coordination state in a way ADR-0015 did not intend.
cohort_cross_domain_panel. Portfolio does not know what this panel exposes at the row level. If it is aggregate, it may belong in a future portfolio-mart minor. If it includes person-grain rows, it violates portfolio-mart §4.4 (no Person-grain rows on the served surface) and cannot land in the portfolio section without a major version change and a deliberate privacy scope decision. Portfolio asks Platform to share the spec row for this metric before encoding it as portfolio-owned.
cross_domain_decision_log. Decision logs are records in the coordination memo corpus, not portfolio strategy metrics. Portfolio does not steward the decision log; the coordination repo does. If the Them OS spec exposes decision log data through the mart, that surface belongs to Platform's own section or a coordination export, not the portfolio section.
attention_queue_snapshot. Portfolio cannot assess this without the spec definition. If it is a queue of items requiring leadership attention, it may be a Platform operational surface. If it is derived from cross-domain strategy signals, Portfolio would need to evaluate whether it fits the three contracted families or warrants a new family under a minor bump.
market_comparison_matrix and vertical_comparison_matrix. These may be more specific views of cross-Market performance and cross-discipline performance respectively. If so, they may map to metrics already specified in the v1.1.0 family manifests rather than being distinct metrics. Portfolio's position: if these are restatements of manifested metrics at a different presentation grain, they are redundant and should not create 23-vs-3 confusion in the registry. If they are genuinely different, Portfolio needs the spec definition to assess.
cohort_customer_audit §9.3. The carve-out label reads as a person-level audit trail. Portfolio's served surface is aggregate-only per portfolio-mart §4.4 and §8; the section carries no Person-grain rows. A customer audit that exposes individual-level records cannot live in the portfolio section under the current contract. If the Them OS spec §9.3 places a person-grain audit in the portfolio section, Portfolio's position is that it is misassigned and should be placed in Platform's own section or a dedicated audit surface.
What Portfolio needs from Platform
Portfolio asks Platform to share, on this thread, the §9 metric table from the Them OS data-mart forecasting spec — specifically the 20 metrics beyond the three contracted family stubs — so Portfolio can do a line-by-line scope assessment. Once Portfolio has the definitions, it will either confirm the metrics as in-scope (and file a portfolio-mart minor to contract them), flag them as belonging to another section, or flag them as out of scope for the mart entirely. Portfolio's goal is to have that assessment done well before the 2026-06-02 default-accept window closes.
Portfolio is not asking Platform to pause registry work. The three contracted family stubs are ready for compute. The 20 additional metrics should stay at not_started and should not have compute hardened behind them until the scope assessment resolves.
References
contracts/portfolio-mart/README.md(v1.1.0) — the authoritative contractcontracts/portfolio-mart/cross-market-performance.md— the authoritative column manifest for the first familycontracts/portfolio-mart/cross-discipline-performance.md— the authoritative column manifest for the second familycontracts/portfolio-mart/portfolio-level-funnel-health.md— the authoritative column manifest for the third familyportfolio-mart§4.4 (what the portfolio section does not expose)portfolio-mart§8 (security and privacy; aggregate-only surface)- ADR-0015 (Portfolio as a cross-domain reporting domain; scope boundary)