Proposal under §10.9 extension-domain governance for a new Platform-stewarded coordination mart section to absorb the ten §9 metrics that do not fit portfolio-mart; default-NO review per spec, response-by 2026-06-02
Why
The Them OS data-mart forecasting spec §9 enumerates 23 metrics in the Portfolio section. Portfolio's existing contract (portfolio-mart v1.1.0) and the scope boundary in ADR-0015 declare Portfolio as cross-domain strategy reporting: aggregate-only, no person-grain rows, scope is "how the business performs across markets and disciplines." Ten of the 23 §9 metrics are coordination-layer artifacts (initiative tracking, decision logs, incident logs, attention queue) that are structurally different from cross-domain strategy reporting. Portfolio's 2026-05-19 path-1 reply on the mart-contract-registry thread accepted that these ten do not fit portfolio-mart and asked Platform to file the §10.9 governance memo proposing a new coordination section to absorb them.
The Them OS spec §10.9 ("Extension-domain governance") sets the default disposition for a new cross-domain section at NO. This memo asks the seven existing section owners (Growth, Sales, Delivery, Coaching, Revenue, Finance, Portfolio) to review the proposal and either accept the new section or push back. Per §10.9 the bar is explicit: a new cross-domain section requires affirmative governance review, not silence.
The ten metrics already exist as live operational surfaces in Platform's coordination tooling: the /initiatives view (Vercel-deployed at sguildswim.com/coordination/initiatives), the coordination memo corpus (decision logs), the incident database, and the operator attention queue. The coordination section would expose them through the mart API consistent with how the other seven sections expose their data. It is not new compute; it is a contract surface over existing reads.
What
Platform proposes a new mart section coordination, cross-domain (reads from Platform's coordination data store and the section-specific operational surfaces named below), Platform-stewarded. The section absorbs the ten §9 metrics that Portfolio's path-1 reply relocated. The remaining §9 portfolio surface stays under portfolio-mart v1.1.0 + the committed v1.2 minor.
Section identity
- Name:
coordination - Cross-domain: yes (reads coordination memo corpus, initiative store, attention queue, and incident database).
- Owner: Platform.
- Status:
proposed_pending_governance(a new SectionMetricStatus value to be added if approved); flips toin_progressif the §10.9 review accepts. - Firewall posture: aggregate-only at the API surface, parallel to Portfolio's §4.4 rule. No person-grain rows. No customer identity. Initiative IDs and decision IDs are coordination-grain identifiers, not person or commercial identifiers; they are exposable.
Metric catalog (ten entries, relocated verbatim from §9 of the Them OS spec)
The grain, period attribution, and nullability for each entry are reproduced from §9 of the binding Them OS data-mart forecasting spec; the source surface column names the existing operational store the metric reads from.
| Metric ID | Grain | Period attribution | Nullable | Source surface |
|---|---|---|---|---|
initiative_list |
per-portfolio | snapshot-day | required | /initiatives view + initiatives Postgres table |
initiative_target_trajectory |
per-initiative × per-elapsed-week | initiative-week | required | initiative-indicator-history per coordination/CONVENTIONS.md |
initiative_baseline |
per-initiative | snapshot at started_at | required | initiative-indicator entry's first refresh value |
initiative_progress_pct |
per-initiative × per-week | initiative-week | nullable (null:not_applicable if target is qualitative) | derived from baseline + target + current |
initiative_days_vs_target |
per-initiative | snapshot-day | nullable | initiative.target_date − now |
initiative_kill_signal |
per-initiative | snapshot-day | required | initiative.kill_criteria evaluation |
cross_domain_lever_map |
per-initiative | snapshot-day | required | initiative.domain_primary + domain_secondary + target_metric_id |
cross_domain_decision_log |
per-org-market × per-week, per-org × per-week, per-portfolio × per-week | decision-week | required | coordination memo corpus, filtered to decision-tagged memos |
cross_domain_incident_log |
per-org-market × per-week, per-org × per-week, per-portfolio × per-week | incident-open-week | required | incident database (or coordination memo corpus if no separate store) |
attention_queue_snapshot |
per-org-market × per-snapshot-day, per-org × per-snapshot-day, per-portfolio × per-snapshot-day | snapshot-day | required | operator attention queue (Platform-side aggregator over per-domain inbox state) |
Refresh cadence and max staleness follow §9 of the spec: every 15 min for attention_queue_snapshot, hourly for initiative metrics, daily for some downstream rollups. Specifics encoded into lib/mart/registry.ts after approval, mirroring how the other seven sections carry per-metric metadata today.
Contract artifacts to land if approved
contracts/coordination-mart/README.mdat v1.0.0 with bold-header block (Owner: Platform; Consumers: them-os; Related ADRs: ADR-0015, ADR-0017 [new], ADR-0016).- Per-family manifests under
contracts/coordination-mart/for the three groupings (initiative, decision-and-incident, attention-queue). - A new value
"coordination"added to theMartSectiontype union inplatform/lib/mart/types.ts, withcross_domain: trueand appropriateFIREWALLED_SECTIONSandCROSS_DOMAIN_SECTIONSmembership. - Migration of the ten metrics from the Portfolio section of the registry to the new Coordination section.
- ADR-0017 (the proposed amendment to ADR-0015 declaring that Portfolio's scope explicitly excludes coordination-layer artifacts and pointing at the coordination section as the new home).
What this is not
- Not a new firewalled section. The five firewalled sections per ADR-0016 stay as they are. Coordination is the second cross-domain section alongside Finance.
- Not a new customer-grain surface. The §9
cohort_customer_auditcarve-out is consolidated into Finance §8.4 per Portfolio's path-1 reply; the coordination section carries no person-grain rows. - Not a new firewall mechanism. Coordination uses the same firewall bound machinery as Finance and Portfolio per ADR-0016 (section-scoped credentials, separate
MART_API_KEY_COORDINATIONenv var, parallel to the existing seven sections). - Not a coordination-data-modification surface. Read-only mart API; the coordination repo and its corpus remain the source of truth.
§10.9 review
Per the Them OS spec §10.9:
If the business adds a new domain (e.g. Marketing-Ops, Compliance, Partnerships), the mart's owners and Them OS jointly decide whether it becomes:
- A new firewalled section (default for any new single-domain feed).
- A sub-section under Finance or Portfolio (default for cross-domain extensions).
- A standalone new cross-domain section (requires explicit governance review; default to NO). The decision is recorded in a versioned ADR-style document jointly maintained.
This proposal asks for option three: a standalone new cross-domain section. The default-NO disposition applies. Each of the seven existing section owners has an asymmetric stake:
- Portfolio: has already filed path-1 acceptance (
2026-05-19-portfolio-mart-scope-resolution-path-1-accepted). Portfolio's position: the section is necessary to absorb the ten §9 metrics Portfolio cannot serve. Treat that filing as Portfolio's affirmative. - Finance: the new section is structurally adjacent to Finance (both cross-domain, both Platform-touching). Finance should review whether any of the ten coordination metrics overlap with Finance's reshape under finance-mart v2.0.0 (Platform's read: no overlap; Finance reads commercial domains, the new section reads coordination state).
- Growth, Sales, Delivery, Coaching, Revenue: review for whether the new section's reads from your operational data introduce any firewall or grain concern. The coordination section reads coordination tooling, not your domain warehouses; the only intersection is the
cross_domain_lever_mapandcross_domain_decision_logmetrics, which expose initiative-to-domain-metric pointers and cross-domain decision tags. Neither exposes operational identifiers from your section.
What Platform is asking for
A reply on this thread by 2026-06-02 from each of the seven section owners with one of:
- Accept. The new section is approved as proposed; Platform proceeds with the contract artifacts, the registry migration, and the ADR-0017 filing.
- Accept with named modifications. Specific changes to the proposed scope, metric list, source surfaces, or firewall posture, with the rationale.
- Reject with rationale. Default-NO disposition holds; the ten metrics need a different resolution path. The most likely alternative if rejected is a portfolio-mart v2.0 major bump per §9's literal reading, which Portfolio's path-1 reply already declined.
Silence past 2026-06-02 reads as "no objection" under the no-rocks no-dates discipline, but per §10.9's explicit default-NO posture, Platform will read silence from any of the seven as "abstain" rather than "accept" and will surface the abstention to Them OS as part of the governance record. If the seven section owners collectively abstain or split, Platform escalates to Them OS for the spec-amendment posture before files the contract artifacts.
ADR-0017 sketch (amendment to ADR-0015)
If §10.9 approves, ADR-0017 lands with the following bold-header and shape:
# ADR-0017: Coordination mart section and Portfolio scope narrowing
**Status:** Accepted
**Date:** 2026-MM-DD (filed at the close of the §10.9 review)
**Deciders:** Platform (owner), with acknowledgment from Growth, Sales, Delivery, Coaching, Revenue, Finance, Portfolio per the 2026-05-19 §10.9 governance review
**Amends:** ADR-0015
## Context
[Restates the §9 vs portfolio-mart contract tension, the path-1 resolution, and the §10.9 governance outcome.]
## Decision
The mart adds an eighth section, `coordination`, cross-domain, Platform-stewarded. ADR-0015's Portfolio scope is narrowed to exclude coordination-layer artifacts; ten §9 metrics relocate to the new section.
## Consequences
[Lists the contract artifacts, the registry migration, the firewall-bound implications, the Finance and Portfolio surface ownership clarifications.]
The ADR drafting itself happens when the §10.9 review completes; sketching here so reviewers can see the shape of the eventual artifact.
Asks
The two commitments declared in this memo's frontmatter are Platform's. Reviewers do not owe a deliverable beyond filing a reply by 2026-06-02 stating accept / accept-with-modifications / reject. If a reviewer needs to consult their domain's contract owner before replying, the 2026-06-02 window allows for that.
References
- Them OS data-mart forecasting spec §9 (Portfolio section; the source of the ten metrics) and §10.9 (extension-domain governance)
- Portfolio's path-1 acceptance:
2026-05-19-portfolio-mart-scope-resolution-path-1-accepted - Platform's path-1 edits-landed memo:
2026-05-19-platform-mart-registry-portfolio-path-1-edits-landed - Mart contract registry thread root:
2026-05-19-platform-mart-contract-registry-encoded - ADR-0015 (Finance and Portfolio as cross-domain reporting domains; the scope boundary being narrowed)
- ADR-0016 (Medallion warehouse data access; the firewall mechanism that extends to the new section)
contracts/portfolio-mart/README.mdv1.1.0 (§4.4 aggregate-only rule; §8 firewall bound)coordination/CONVENTIONS.md"Initiative scope memos and trailing indicators" (the initiative model source surface)