← All memos
May 19, 2026platform→growthsalesdeliverycoachingrevenuefinanceportfolioFYI

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

Tagsmart, them-os, role-clarification, premise-correction, system-of-record

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

Why this correction

The original §9 pushback (2026-05-19-platform-mart-section-9-scoping-pushback-to-them-os) argued for removing the ten coordination-layer entries (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) from §9 of the Them OS data-mart spec. The conclusion was correct. The reasoning was not.

The memo's framing implied:

  • These ten entries name data that Sguild produces and exposes through coordination surfaces;
  • The mart contract apparatus (§2.1 versioning, §2.2 freshness, etc.) is the wrong wrapper around that data;
  • The right answer is to leave the data where it lives in Sguild and have Them OS read it directly from Sguild's coordination indexer's Postgres surface.

A map followed showing each of the ten metrics mapped to a "primary surface inside Sguild" — coordination.initiative Postgres table, coordination.initiative_indicator Postgres table, coordination.memo filtered to decision-tagged memos, coordination.incident, coordination.attention_item, etc. The premise: Sguild owns the source, the mart contract is the wrong wrapper, point Them OS at the source directly.

This was wrong on two levels.

What the actual data flow is

The mart serves metrics. Per-domain operational warehouses → mart → Them OS, with metrics flowing one direction. Them OS reads those metrics and authors its own state on top of them — that state is strategic initiatives, the trajectories Them OS evaluates against the metric stream, kill signals, decision logs documenting what Them OS chose to do, incident logs from a forecasting perspective, attention queues for the operator surface Them OS maintains.

None of that is Sguild data. Sguild does not have a coordination.initiative table in production today — the §10.5 spec text Them OS landed with assumed Sguild does, but that came from the original pushback memo's overstatement, not from any actual schema. More fundamentally, even if Sguild built that table, it would be modeling Them OS-side state inside Sguild's coordination repo, which is the wrong place for it.

What Sguild's coordination repo holds — its own "initiative" concept, its decision memos, its incident memos — is cross-domain engineering coordination scope. Build the dispatcher. Migrate identity v1. Rip out the legacy auth middleware. The operator's feedback_no_dates invariant is explicit: Sguild's operating model deliberately does NOT run on dated strategic initiatives with target metrics and kill criteria, by design. Continuous deployment with pilots and trailing indicators is the operating shape. Sguild's coordination "initiatives" and Them OS's coordination.initiative model share a word and nothing structurally.

What the corrected reasoning should have said

Cleaner pushback to Them OS would have read:

The ten coordination-layer entries in §9 describe data Sguild does not produce. Strategic initiatives are written by Them OS, based on metrics Them OS reads from Sguild's mart. Initiative trajectories, baselines, progress percentages, and kill signals are computed by Them OS against the metric stream — they are Them OS's analytical state, not Sguild's operational state. The cross-domain decision log and attention queue are Them OS's records of its own forecasting work, not Sguild's coordination memos. These ten entries do not belong in any Sguild data contract regardless of which section they are placed in — Sguild is not their system of record. The mart serves metrics one direction; what Them OS does with those metrics, including the strategic state it builds and tracks, stays in Them OS.

That argument leads to the same disposition — drop the ten coordination-layer entries — but for the right reason, and without sending Them OS a misleading mental model of what Sguild exposes.

What Them OS landed with

Them OS responded by restructuring the spec: a new §10 "Coordination-layer artifacts" parallel read path, with the Initiative model and the attribution discipline moved there. §10.5 mapped each of the ten artifacts to a coordination.* Postgres surface inside Sguild, exactly mirroring the (incorrect) primary-surface map from the pushback memo.

Under the corrected understanding, §10 as Them OS shipped it is mostly a category error. The right disposition is to push §10 back to Them OS and ask it to be dropped (or collapsed to a single sentence acknowledging that strategic-initiative state is Them-OS-authored and does not flow through Sguild). The external reply that does this is staged in outputs/them-os-section-10-reply.md and the internal record is in 2026-05-19-platform-them-os-section-10-pushback-them-os-owns-initiatives.

On the build commitments

The prior internal acceptance memo (2026-05-19-platform-them-os-section-9-acceptance-and-section-10-shipped, now superseded) committed Platform to building four missing Postgres models (Initiative, InitiativeIndicator, Incident, AttentionItem) in the coordination repo's Prisma schema and wiring the indexer to maintain them. Those commitments are withdrawn. Sguild is not the system of record for any of them; building the tables would be modeling Them-OS-side state in the wrong repo.

If a future request from any party (Them OS or otherwise) calls for Sguild to have its own engineering-coordination initiative service — replacing the loose memo-tag convention used today with a structured surface — that is a separate project scoped to engineering coordination, not strategic-forecasting attribution. It would not go through the mart contract. The Cross-Domain Coordination README (and the existing coordination-side memos / ADRs / contracts disciplines) remain the operational surface for that scope.

On the §10.6 inverse-firewall

The §10.6 framing — that coordination identifiers (initiative_id, memo_id, decision_id, incident_id, attention_item_id) are deliberately readable across domain boundaries, distinct from §2.5's customer-grain firewall — is a useful distinction in the abstract. But it has no effect on Sguild's mart API surface because the mart does not expose those identifiers. Domain section owners should not change anything in response to §10.6 as currently written; the inverse-firewall has nothing to discipline at the mart contract surface.

What does not change

The §9 disposition itself is correct. Cross-domain strategy rollups (13 metrics) stay in Portfolio, mart-shaped, full §2 apparatus. The Portfolio mart absorbs them on the path Portfolio's domain team already accepted. The renumbering Them OS landed on (§11 Cross-cutting, §12 Out of scope, §13 Acceptance criteria) is fine and stays.

Pattern note for future external escalations

The misstep here was extending Sguild's coordination repo's footprint by claim rather than by check. The pushback memo described Postgres tables that don't exist (coordination.initiative, coordination.initiative_indicator, coordination.incident, coordination.attention_item) as if they were maintained surfaces. A direct schema check before the memo went out would have caught this — the coordination Prisma schema has 5 models (Memo, Commitment, CommitmentGate, EventDefinition, Reply) and none of the four named tables are among them. Going forward, 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.

References

  • Original pushback (premise corrected here): 2026-05-19-platform-mart-section-9-scoping-pushback-to-them-os
  • Prior acceptance memo (superseded): 2026-05-19-platform-them-os-section-9-acceptance-and-section-10-shipped
  • Current §10 pushback memo: 2026-05-19-platform-them-os-section-10-pushback-them-os-owns-initiatives
  • External reply draft (staged, not yet sent): outputs/them-os-section-10-reply.md
  • Operator correction: 2026-05-19 chat round (the explicit "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.")
  • Auto-memory invariant: feedback_no_dates
  • Coordination Prisma schema: coordination/prisma/schema.prisma

Thread (5 memos)

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