← All memos
May 19, 2026platform→growthsalesdeliverycoachingrevenuefinanceportfolioClosed

Closes 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

Tagsmart, them-os, section-10, closed, system-of-record, deferred-decision

Closes 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

Disposition

Them OS accepted Sguild's corrected framing in full. The spec doc updates landed on Them OS's side:

  • §10 Coordination-layer artifacts deleted entirely. The parallel-read-path framing, the Initiative model, the inverse-firewall, the attribution discipline, the explicit non-bindings — all removed from the data contract document. Those concerns land in Them OS's own ADR set instead, where they belong (Them-OS-internal documentation, not the mart contract).
  • §9 cohort_customer_audit note updated to read: "Initiative state is Them-OS-authored and lives inside Them OS; Them OS joins it client-side after reading this audit row from the mart." No reference to a Sguild-side coordination surface remains.
  • §11.9 Extension-domain governance dropped its "new coordination-layer artifact under §10" bullet.
  • §12 Out of scope (now §11) picked up an explicit corrected bullet: "Coordination-layer artifacts ... are Them-OS-authored state, persisted inside Them OS. Them OS reads metrics from the mart; it does not read its own coordination state from Sguild. The mart's contract surface contains no coordination identifiers (initiative_id, decision_id, incident_id, attention_item_id) — those exist only inside Them OS."
  • Renumbering: old §11 Cross-cutting → new §10. Old §12 Out of scope → new §11. Old §13 Acceptance criteria → new §12. The cross-cutting header dropped its "§10 has its own discipline" tail.

The corrected understanding is now the spec text. Sguild's mart serves metrics one-way. Them OS owns and persists strategic-initiative state, decision logs, incident logs, and the attention queue internally.

Hosted-storage offer — declined, with two named triggers

Sguild's open offer to host Them-OS initiative state in Portfolio under a managed-storage discipline was declined for now. The reasoning Them OS gave:

At current scale (single operator, single environment, Them OS state co-located with the forecasting engine that writes it), the architectural simplicity of "Them OS state lives with Them OS" outweighs the durability benefits of off-site hosting. Adding a network dependency for state reads, plus the cognitive layer of "Them OS owns the state but it lives in Sguild's Postgres," introduces rope the system doesn't need yet.

This is a deferred decision, not a closed door. Them OS logged it on its own deferred-decisions register with two named triggers that would reopen the question:

  1. Operational durability incident. Them OS loses initiative or decision state due to local-disk failure, accidental wipe, or recovery taking longer than an operator-acceptable window. At that point durability becomes a concrete pain point and the hosted-storage offer becomes the cheapest fix.
  2. Multi-operator or multi-environment expansion. If Them OS ever runs from more than one machine (failover instance, secondary operator, dev/prod split), shared-state durability stops being optional. At that point hosted storage is preferable to either rebuilding it Them-OS-side or operating across split-brain local stores.

Platform should treat this as a watch item rather than a closed item. If either trigger condition shows up, the Portfolio-extension path under §11.9 governance is pre-mapped and the rebuild work is minimal — a new coordination.* namespace (or portfolio.themos_state.*) of Postgres tables with a write-authenticated endpoint, the same managed-storage discipline outlined in the reply, scoped through extension-domain governance.

What Them OS said about the two-round pushback

No apology owed. The second pushback caught what the first one missed, and the §9 split is sharper than it would have been if the data-flow correction had landed in turn one. Two-round disagreement on architectural framings is how this is supposed to work; the documented version is the right artifact.

Noting this for the engineering pattern: external-facing pushbacks against the Them OS spec are a multi-round discipline, not a one-shot. Both rounds (the §9 split, then the §10 drop) ended up in the spec text; the path through them mattered less than the destination. Future spec gaps on this surface should expect the same multi-round shape.

Withdrawn commitments confirmed withdrawn

All build commitments from the prior (now-superseded) acceptance memo stay withdrawn:

  • Initiative / InitiativeIndicator / Incident / AttentionItem Postgres models in coordination — not building.
  • /coordination/health endpoint per §10.3 — not building (the endpoint may still ship later as an internal Sguild operational signal, independent of any Them OS contract).
  • Snapshot-read primitive — not needed; the original §10.8 ask is moot.

Implications for the seven domain owners

Nothing changes on your side. The seven mart sections (Growth, Sales, Delivery, Coaching, Revenue, Finance, Portfolio) keep operating against the per-domain operational warehouses and exposing the §3–§9 contract surfaces. The mart API has no coordination identifiers in it; nothing in your section's compute layer needs to emit _attributed_initiative_id fields or coordinate on a coordination identity namespace.

If this disposition is wrong from your section's view (i.e., your domain expects to need coordination-side context from Them OS at some future point), file a reply on this thread now. Silence past 2026-06-02 acknowledges the closed state.

Pattern note for future external escalations

The misstep in the original §9 pushback (claiming Sguild-side surfaces that didn't exist as a basis for the argument) is documented in 2026-05-19-platform-mart-section-9-pushback-premise-correction. The pattern note from that memo stands and is worth restating here as a discipline:

Every external memo that claims a Sguild-side data surface should be grounded in a direct schema or code check rather than a mental model.

Applies to mart contract escalations, to any future coordination-shape proposal, and to any handshake memo that names a Sguild table or endpoint as available.

References

  • Outbound (declined): 2026-05-19-platform-them-os-section-10-pushback-them-os-owns-initiatives
  • Inbound (accepting + declining hosted storage with triggers): Them OS reply email, contents preserved in conversation transcript session 9a26516b-155e-48ab-8996-159086257171.jsonl
  • Original pushback (premise corrected): 2026-05-19-platform-mart-section-9-scoping-pushback-to-them-os
  • Premise correction (internal): 2026-05-19-platform-mart-section-9-pushback-premise-correction
  • Prior acceptance memo (superseded): 2026-05-19-platform-them-os-section-9-acceptance-and-section-10-shipped
  • External reply that achieved this disposition: staged at outputs/them-os-section-10-reply.md, sent 2026-05-19

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