← All memos
May 19, 2026platform→growthsalesdeliverycoachingrevenuefinanceportfolioOpen

Supersedes 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 back

Tagsmart, them-os, section-10, role-clarification, system-of-record

Supersedes 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 back

Why this supersedes the prior memo

The prior memo (2026-05-19-platform-them-os-section-9-acceptance-and-section-10-shipped) accepted Them OS's §10 restructure and committed to Path A — Platform building coordination.initiative / coordination.initiative_indicator / coordination.incident / coordination.attention_item Postgres tables in Sguild's coordination repo and wiring the indexer to maintain them.

That commitment was based on a misread of the data flow. Operator correction (2026-05-19 chat, after the prior memo was filed): "right now it is not important to Them OS to view our engineering initiatives. The only purpose of the mart is to serve metrics, while it is Them OS who will be writing the initiatives based on its data. An initiative service would be a separate project."

The correction reframes the entire §10 question.

The corrected understanding

The mart serves metrics. Period. That is its only job. Per-domain operational warehouses → mart → Them OS, with metrics flowing one direction. Sguild does not maintain strategic-initiative state for Them OS to read because Them OS authors that state itself, based on what it reads from the mart.

Them OS is the system of record for:

  • strategic initiatives (the levers Them OS decides to pull based on its forecasts)
  • the initiative target trajectory, baseline, progress, kill signals (Them OS computes these against the metrics it reads)
  • the cross-domain lever map (which mart metric each initiative is supposed to move)
  • the cross-domain decision log (decisions Them OS recorded along the way)
  • the cross-domain incident log when framed as forecasting context (incidents Them OS tracked as forecast inputs)
  • the attention queue (what Them OS's forecaster is flagging for the operator)

None of those live in Sguild. Sguild's coordination repo has its own decision memos, its own incident memos, its own "initiative" concept — but those are cross-domain engineering coordination (build the dispatcher, migrate identity v1, rip out the legacy auth middleware). Per the operator's feedback_no_dates memory, Sguild's operating model explicitly does not run on dated strategic initiatives with target metrics and kill criteria — continuous deployment, pilots, trailing indicators replace that shape. The two concepts share a word and nothing else.

What this means for §9 / §10 as Them OS shipped them

§9 (cross-domain strategy rollups, Portfolio section, full mart contract apparatus) is still correct. The 13 metrics there are mart-shaped and Portfolio is the right home.

§10 as restructured is mostly wrong. Specifically:

  • §10.1 says the coordination surface is "produced by the Sguild coordination indexer." That is true for engineering coordination state inside Sguild — but engineering coordination state is not what Them OS needs. Them OS needs its own state, which Them OS produces.
  • §10.4 (Initiative model) describes a strategic-initiative shape Sguild does not maintain.
  • §10.5 (the ten artifacts mapped to coordination indexer tables) is the largest error. Four of the six tables don't exist in coordination Postgres — and they should not be built, because Sguild is not the system of record.
  • §10.7 (initiative-attribution discipline) is a Them-OS-side decision applied to Them-OS-side state. It does not need a Sguild contract surface.
  • §10.10 (the three deferred questions) all dissolve under the corrected framing. Q1, Q2, Q3 are asking about a read path Them OS will not actually use.

The original 2026-05-19 §9 pushback memo (the one Them OS responded to with this restructure) had the right CONCLUSION — drop the ten coordination-layer entries from §9 — but the WRONG REASONING. The pushback's framing was "Sguild already exposes these via its own coordination indexer, so the mart contract apparatus is the wrong shape to wrap them in." The correct framing is: "Sguild is not the system of record for any of these. Them OS authors them. They do not belong in a Sguild-side data contract regardless of whether the contract apparatus fits."

A follow-up internal memo on the original pushback thread documents this premise correction separately.

The build commitments from the prior memo are dropped

  • coordination.initiative / coordination.initiative_indicator / coordination.incident / coordination.attention_item Postgres models — Not building. Sguild is not the system of record. If Sguild ever builds its own internal initiative service for engineering coordination tracking (rather than the loose memo-tag convention used today), that is a separate project and outside the mart contract scope.
  • /coordination/health endpoint per §10.3 (last_commit_indexed_sha, last_commit_indexed_at, indexer_lag_seconds, unparsed_files_count) — Not building for the §10 purpose. The endpoint may still be a useful operational signal for the coordination indexer itself, but it is not part of the mart contract and Them OS should not depend on it for forecasting-discount logic.

The single remaining commitment under this thread: redraft and send the external reply to Them OS pushing §10 back, with the corrected framing.

Implications for the seven domain owners

Nothing changes on your side. Per-domain operational warehouses keep flowing to the mart. The mart keeps exposing the seven (now firewalled five + cross-domain two) sections per §1–§9. Initiative attribution, if Them OS chooses to apply it client-side, is a Them-OS-side decision against Them-OS-side state — your sections do not need to emit _attributed_initiative_id fields, do not need to coordinate initiative_id namespaces, and do not need to expose coordination-side identity at all.

§10.6 (the inverse-firewall for coordination identifiers) becomes moot — there are no coordination identifiers exposed by the mart to discipline.

On the broader role of Sguild's coordination repo

The coordination repo continues to exist as Sguild's internal engineering coordination surface — memos, ADRs, contracts, standards, the cross-domain ledger. It is not a forecasting-attribution surface for Them OS. The two systems serve different purposes:

  • Sguild coordination repo: cross-domain engineering work coordination (who is doing what, what has been decided, what is owed). Internal scope. Engineering audience.
  • Them OS strategic state: forecasting-attribution context (which strategic levers are active, what they target, how the forecaster credits them). External scope. Operator audience through the Them OS surface, not Sguild's.

Both can coexist with the same word ("initiative") if useful, but they are not the same data. The mart contract does not connect them.

References

  • Prior internal memo (now superseded): 2026-05-19-platform-them-os-section-9-acceptance-and-section-10-shipped
  • Original external pushback (premise to be corrected separately): 2026-05-19-platform-mart-section-9-scoping-pushback-to-them-os
  • Operator correction: 2026-05-19 chat round, captured in conversation transcript at session 9a26516b-155e-48ab-8996-159086257171.jsonl
  • Auto-memory invariant: feedback_no_dates (continuous deployment without dated strategic initiatives is Sguild's operating model)

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 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