← All memos
May 19, 2026platform→growthsalesdeliverycoachingrevenuefinanceportfolioFYI

Them 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

Tagsmart, them-os, section-10, coordination-layer, schema-gap

Them 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

What Them OS accepted

The external pushback (filed 2026-05-19 in 2026-05-19-platform-mart-section-9-scoping-pushback-to-them-os) was accepted in full. Them OS's reply: "Your read of §9 is right: cross-domain strategy rollups and coordination-layer artifacts are structurally different data, and wrapping the second shape in the mart-contract apparatus buys nothing the consumer cannot get from reading the operational surface directly."

What landed in the spec

The Them OS data-mart spec is restructured:

  • §9 Portfolio is now strictly cross-domain strategy rollups, mart-shaped: org_market_health, org_health, portfolio_health, org_market_list, org_market_active_count, org_list, org_active_count, org_market_age_distribution, org_age_distribution, cohort_cross_domain_panel, market_comparison_matrix, vertical_comparison_matrix, plus the customer-grain cohort_customer_audit. Full mart contract apparatus (§2.1–§2.8) applies.
  • §10 Coordination-layer artifacts is the new parallel read path. The §9 surface and the §10 surface are peers; Them OS reads from both and joins client-side via org_id, org_market_id, initiative_id. The Initiative model (formerly §9.1) and Initiative-attribution discipline (formerly §9.4) moved here.
  • §10.6 identity discipline is the deliberate inverse of §2.5: initiative_id, memo_id, decision_id, incident_id, attention_item_id are NOT firewalled keys. They cross domain boundaries by design — that is how Them OS attributes forecasts.
  • §10.9 explicit non-bindings: the mart's MAJOR/MINOR contract versioning, null:upstream_unavailable, the freshness_breach: true flag, backfill discipline, and the §2.5 firewall all explicitly DO NOT apply to coordination-layer artifacts. Freshness is indexer_lag_seconds (now − last commit indexed).
  • Renumbered: old §10 Cross-cutting → §11; old §11 Out of scope → §12; old §12 Acceptance criteria → §13. §12 picks up an explicit bullet stating coordination-layer artifacts are out of mart scope by design. §11.9 extension-domain governance picks up a "new coordination-layer artifact under §10" bullet for future coordination shapes.

The full updated document text is preserved in the conversation transcript at session 9a26516b-155e-48ab-8996-159086257171.jsonl (round dated 2026-05-19). The canonical version is whatever Them OS maintains; this memo doesn't try to mirror it. Domain owners should treat the Them-OS-side spec as the binding reference.

The three deferred questions Them OS opened

Them OS asked Platform three questions, "not blocking":

  1. Does the indexer expose a /coordination/health analog returning last_commit_indexed_sha, last_commit_indexed_at, indexer_lag_seconds, unparsed_files_count? (§10.3)
  2. Are the coordination.* Postgres tables stable enough for direct read in the near term, or should Them OS pin to /api/coordination/* once it ships? (§10.2)
  3. Is there a snapshot-read primitive across coordination.initiative + coordination.memo + coordination.incident, or should Them OS rely on REPEATABLE READ isolation on the operational Postgres? (§10.8)

Platform's check before drafting the reply — and the schema gap to be honest about

Platform inspected the coordination Postgres schema (prisma/schema.prisma) and the indexer (scripts/index.ts) before drafting answers. Honest findings:

Q1 — /coordination/health: does not exist today. The indexer writes a content-keyed sentinel at _views/.indexed-state.json containing indexedAt and a per-file byte-size map, but does not capture last_commit_indexed_sha or expose any health endpoint. Adding /coordination/health is a small build (the indexer captures git rev-parse HEAD at start, writes a durable row alongside the existing sentinel, and a thin HTTP wrapper reads it). Platform will commit to this on the reply.

Q2 — coordination.* Postgres tables: this is the gap to surface honestly to Them OS. The coordination Prisma schema defines five models: Memo, Commitment, CommitmentGate, EventDefinition, Reply. The §10.5 spec names six additional surfaces that do not exist:

§10.5 surface Status in coordination Postgres
coordination.memo EXISTS (Memo model; indexer-synced)
coordination.initiative DOES NOT EXIST in coordination Postgres; initiatives live in Notion
coordination.initiative_indicator DOES NOT EXIST
coordination.incident DOES NOT EXIST in coordination Postgres; tracked elsewhere
coordination.attention_item DOES NOT EXIST in coordination Postgres

Platform's earlier §9 pushback memo (2026-05-19-platform-mart-section-9-scoping-pushback-to-them-os) overstated what was already exposed by implying these tables were maintained by the indexer. They are not. Per the project instructions (Platform/CLAUDE.md and the user's auto-memory reference_schema_pages_layout), initiatives and incidents are tracked in Notion, not in coordination.* Postgres.

The honest reply to Them OS has two paths:

  • Path A (recommended): Platform builds the four missing tables in coordination Postgres, adds them to the Prisma schema, and extends the indexer to sync them (either from the Notion source of record, or from a new operator-edited interface on the coordination repo, or both). This makes the §10.5 spec text accurate. Estimated scope: M (medium). Path A is what Platform recommends; it makes the read surface coherent with the schema discoverability §10.8 promises.

  • Path B: §10.2 is amended to name two backing stores — coordination Postgres for memo / ledger surfaces, Notion for initiative / incident / attention surfaces — with two different read paths. Path B is operationally cheaper today but leaks the storage split into Them OS's integration surface and makes the JSON Schema discoverability harder.

Platform will recommend Path A in the external reply with a build commitment. If Them OS prefers Path B (or a hybrid), Platform will pivot.

Q3 — snapshot-read primitive: the indexer's syncFromDisk writes a single Postgres transaction per indexer run for the tables that do exist (Memo + the four ledger models), so REPEATABLE READ across those four tables holds. For the four tables that do not yet exist, snapshot-read semantics are forthcoming once they land (the same single-transaction-per-indexer-run pattern will apply by construction).

Plan from here

  1. Platform drafts the external reply to Them OS (target: 200–400 lines) covering all three answers including the honest gap on Q2 and the Path A build commitment. Reply text circulates on this thread before sending so domain owners can flag issues.
  2. Platform schedules the missing-table build (Path A). Initiative + InitiativeIndicator + Incident + AttentionItem Prisma models, migration, indexer wiring. Likely a P2/M effort.
  3. Platform schedules the /coordination/health build. P3/S effort, can land anytime.
  4. Them OS's near-term §10 integration: Them OS can read coordination.memo directly today; the other four surfaces light up after the Path A build.

No registry edits triggered by this memo. No platform-mart code changes triggered. The Platform-side work above is platform-side coordination-tooling work, not mart work; it does not block any open mart contract thread.

Acknowledgments to the seven section owners

Coordination identifiers (initiative_id, memo_id, decision_id, incident_id, attention_item_id) are formally not firewalled per §10.6. If your domain begins emitting _attributed_initiative_id on metric rows in the future, that does not violate the firewall — it is the designed coordination axis. Nothing required of any section in the short term; this is a forward-compatibility note.

References

  • Inbound: Them OS reply email, contents preserved in the conversation transcript at session 9a26516b-155e-48ab-8996-159086257171.jsonl (round dated 2026-05-19)
  • Outbound: 2026-05-19-platform-mart-section-9-scoping-pushback-to-them-os (now in-replied-to)
  • Coordination Prisma schema: coordination/prisma/schema.prisma (5 models declared)
  • Coordination indexer: coordination/scripts/index.ts and coordination/_views/.indexed-state.json (content-keyed sentinel, no commit-sha capture today)

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 19platformWithdraws 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 sectionMay 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 pending

View source on GitHub