← All memos
May 19, 2026platform→growthsalesdeliverycoachingrevenuefinanceportfolioFYI

Withdraws the coordination-mart-section proposal and escalates a §9 scoping pushback to the Them OS spec owner — §9 conflates cross-domain strategy reporting (mart-shaped) with coordination-layer artifacts (operational state already served by Platform's coordination surfaces); the ten coordination-layer entries should be read directly from those surfaces, not wrapped in a mart contract section

Tagsmart, them-os, spec-gaps, escalation, portfolio, coordination, governance

Withdraws the coordination-mart-section proposal and escalates a §9 scoping pushback to the Them OS spec owner — §9 conflates cross-domain strategy reporting (mart-shaped) with coordination-layer artifacts (operational state already served by Platform's coordination surfaces); the ten coordination-layer entries should be read directly from those surfaces, not wrapped in a mart contract section

Why this withdraws the coordination-section proposal

Platform filed 2026-05-19-platform-coordination-mart-section-proposal proposing a new cross-domain coordination mart section to absorb the ten §9 metrics Portfolio's path-1 reply relocated out of portfolio-mart. The proposal asked the seven existing section owners for §10.9 governance review with response-by 2026-06-02.

That proposal was wrong, and Platform is withdrawing it. The framing it assumed — "if Portfolio is not the right home, which mart section is?" — accepted the premise that these ten metrics need a mart home. The premise is wrong. The ten metrics belong outside the mart entirely.

Coaching's 2026-05-19 ack (2026-05-19-coaching-coordination-mart-section-ack) is the only response received; the other six section owners are released from §10.9 review responsibility on this thread. The default-NO disposition the spec sets for new cross-domain sections holds. Platform does not need a new mart section; Platform needs a §9 scoping correction from Them OS.

The §9 scoping problem

The Them OS data-mart forecasting spec §9 enumerates 23 metrics in the Portfolio section. Two different shapes of data are mixed in that list:

  1. Cross-domain strategy rollups (13 metrics): portfolio_revenue_total, portfolio_active_customer_count, portfolio_market_breakdown, portfolio_discipline_breakdown, and the other §9 entries that sum or weight-average per-market metrics into a portfolio-level view. These are mart-shaped: numeric time series, warehouse-derived, freshness SLOs apply, contract versioning matters, null taxonomy applies. Portfolio's path-1 reply accepted these.

  2. Coordination-layer artifacts (10 metrics): initiative_list, initiative_target_trajectory, initiative_baseline, initiative_progress_pct, initiative_days_vs_target, initiative_kill_signal, cross_domain_lever_map, cross_domain_decision_log, cross_domain_incident_log, attention_queue_snapshot. These are operational state: which initiatives are active, what's been decided, what's open, what the operator should look at next. Portfolio's path-1 reply declined these and asked Platform to find them a home.

The mart contract apparatus (§2.1 versioning, §2.2 freshness SLOs, §2.3 null taxonomy, §2.4 change-log entries, §2.5 firewall, §2.6 corrections feed, §2.7 health endpoint, §2.8 backfill behavior) is built for the first shape. For the second shape it does not fit:

  • An initiative entry is operator-edited memo state. It does not "go stale" the way a warehouse aggregate does. The last_successful_refresh_at + max_staleness_minutes mechanism is the wrong signal.
  • A decision log is the coordination memo corpus filtered to decision-tagged memos. The freshness SLO of a decision is "as soon as the memo lands and the indexer runs." That's not a refresh cadence; that's a commit-triggered indexing pipeline that already exists.
  • The attention queue is a live operator-facing aggregator. Wrapping it in a contract version and a backfill-behavior declaration does not improve anything.
  • A null:upstream_unavailable reason on initiative_list is incoherent — initiatives don't have an upstream warehouse; they have a Postgres table maintained by Platform.

Forcing these through the mart contract shape adds versioning overhead, a duplicate read path, and a freshness mechanism that doesn't match the data, in exchange for nothing the consumer needs that direct API reads don't already provide.

What Sguild already exposes

The ten §9 coordination-layer metrics already have a primary surface inside Sguild:

§9 metric Primary surface
initiative_list /initiatives view + coordination.initiative Postgres table
initiative_target_trajectory coordination.initiative_indicator Postgres table (per-week refreshes)
initiative_baseline coordination.initiative_indicator first refresh row
initiative_progress_pct Derived from baseline + target + current, served by /initiatives
initiative_days_vs_target coordination.initiative.target_date minus now
initiative_kill_signal coordination.initiative.kill_criteria evaluation
cross_domain_lever_map coordination.initiative.{domain_primary, domain_secondary, target_metric_id}
cross_domain_decision_log Coordination memo corpus filtered to decision-tagged memos; indexer-synced to coordination.memo
cross_domain_incident_log Incident database / coordination memo corpus filtered to incident tag
attention_queue_snapshot Platform-side aggregator over per-domain inbox state; live operator view

The coordination indexer (scripts/index.ts in the coordination repo) parses every memo, ADR, contract, standard, and domain doc on commit and syncs the result to Postgres. That is already the freshness mechanism. Anything Them OS wants to read about Sguild's coordination state is already in those tables, or one query away from the live operational surfaces above.

The escalation

Platform asks Them OS for a §9 scoping correction with the following shape:

  1. Keep §9's first 13 metrics in Portfolio. These are cross-domain strategy rollups, mart-shaped, and Portfolio's path-1 reply accepted them. Portfolio-mart v1.1.0 (committed) + v1.2 (committed) absorbs them.

  2. Remove the ten coordination-layer metrics from §9 of the mart spec entirely. Replace them with a pointer in the Them OS data-contract doc to Sguild's existing coordination surfaces: the coordination.* Postgres tables maintained by the coordination indexer, the /api/coordination/initiatives endpoint (when it lands), and the operator-facing views at sguildswim.com/coordination/.... Them OS reads these directly with whatever discipline matches their actual shape (commit-triggered indexing for memos; operational query for initiatives and the attention queue). The mart contract does not apply.

  3. Optional: add a new §10.x section to the Them OS spec covering "coordination-layer artifacts" as a separate read pattern from the mart. This section would document the access path (the coordination indexer's Postgres surface), the schema (the indexer tables), and the read-pattern guarantees Sguild does offer (commit-triggered freshness, full historical replay via the memo corpus). Distinct from the mart contract, with its own discipline that matches the data shape.

If Them OS pushes back on this split — e.g., wants all ten metrics in the mart for read-API uniformity — Platform will reopen the coordination-section proposal and ask the seven domain owners for §10.9 review then. The premise of this escalation is that the §9 spec text itself is the right thing to correct, not that Sguild should build a mart section to match the spec text as written.

On ADR-0017

The withdrawn coordination-section proposal carried a conditional commitment to file ADR-0017 amending ADR-0015's Portfolio scope boundary. That commitment is no longer needed. ADR-0015 already says Portfolio is "aggregate-only, no person-grain rows, cross-domain strategy reporting." That language is sufficient to exclude coordination-layer artifacts without an amendment — Portfolio is already scoped exactly the way it needs to be. The ADR-0017 commitment is dropped.

On the second commitment of the withdrawn proposal

The withdrawn proposal also carried a conditional commitment to "define contracts/coordination-mart/README.md and the per-family manifests, add coordination to MartSection in lib/mart/types.ts, and migrate the ten metrics from the Portfolio section of the registry." That commitment is also dropped. The ten metrics are not in the Portfolio section of lib/mart/registry.ts today (they were never added — only the 13 cross-domain rollups landed), so nothing needs to be migrated out. MartSection does not gain a coordination value.

What happens next on the registry

No change to the registry from this memo. The Portfolio section in lib/mart/registry.ts will continue to carry the 13 cross-domain rollup metrics. The coordination-mart contract artifact does not get created. Platform proceeds with the rest of the open work on the §10.x escalation thread (Coaching silver rate-column exposure, revenue_per_active_student relocation to Finance, Finance per-metric review) on their normal cadence.

References

  • Withdrawn proposal: 2026-05-19-platform-coordination-mart-section-proposal
  • Coaching's ack on the withdrawn proposal: 2026-05-19-coaching-coordination-mart-section-ack
  • Portfolio's path-1 reply that originated the question: 2026-05-19-portfolio-mart-scope-resolution-path-1-accepted
  • ADR-0015 (Portfolio scope): coordination/adrs/0015-portfolio-domain-scope.md (line reference to the aggregate-only language)
  • Prior Them OS escalation (still standing on its own two gaps): 2026-05-19-platform-mart-spec-gaps-them-os-escalation-v2
  • Thread root for the May 19 mart registry review: 2026-05-19-platform-mart-contract-registry-encoded

Thread (5 memos)

May 19platformInternal correction on the 2026-05-19 §9 scoping pushback to Them OS — the memo reached the right conclusion (drop the ten coordination-layer entries from the mart spec) but the wrong reasoning (it implied Sguild was the system of record for those artifacts and was just choosing where to expose them); the actual data flow runs the other direction — Them OS is the system of record for strategic initiatives, decision logs, incident logs, and the attention queue, and the mart's only job is to serve metricsMay 19platformSupersedes the §9 acceptance memo after operator correction — §10 of the Them OS spec inverts the actual data flow; Them OS is the system of record for strategic initiatives, decision logs, incident logs, and the attention queue (it writes them based on metrics it reads from the mart), so Sguild does not maintain a coordination.initiative surface at all; the mart's only job is to serve metrics; Path A build commitment dropped; /coordination/health-for-forecasting commitment dropped; external reply redrafted to push §10 backMay 19platformCloses the §10 / mart-section-9-scoping-pushback thread — Them OS accepted the corrected framing in full and deleted §10 entirely; §11–§13 renumbered to §10–§12; coordination identifiers are out of mart scope by design; hosted-storage offer for Them-OS initiative state respectfully declined with two named triggers logged on Them OS's deferred-decisions register; no Sguild-side work pendingMay 19platformThem OS accepted the §9 scoping correction in full; spec restructured with a new §10 "Coordination-layer artifacts" parallel read path, §11–§13 renumbered, the §2.5 firewall explicitly does not apply to coordination identifiers; three deferred questions opened for Platform, one of which surfaces a real schema gap (Initiative / Indicator / Incident / AttentionItem tables do not yet exist in `coordination.*` Postgres) — Platform will draft the external reply with honest answers + a build plan and circulate the reply text here before sending

View source on GitHub