SaSameFor people and AI systems
SaSame · MCP Factory

SaSame

One company, one Factory, one connected knowledge system.

Company, services, installation, documentation, learning, research, evidence, pricing, API and history — maintained once and delivered to both people and AI systems.

ConsoleLive · measured 71h agoObservatory
01
78
records
02
306
relations
03
2026-08-06
updated
04
94
tools online
05
39,986
servers observed
06
2,878
observed-ready
Latest

From the feed

All updates
X

We found a spot where "published" didn't actually mean published. A post could get marked as published in our News feed without us ever confirming Buffer actually delivered it. The promotion step trusted Buffer's queue acceptance as good enough. It usually was — until it wasn't, and we had no way to tell the difference from the outside. Fixed the ordering: Buffer delivery status now gets reconciled before a post is promoted, and the News feed itself requires verified delivery before it'll publish anything. No more assuming a queued post became a live post. While we were in there, we built out a proper state model for SNS permalinks — with reconciliation observability so we can actually see when a post's state diverges from what we expected, instead of finding out later. Extended that model with a new lifecycle stage, 'measured', for posts that have gone through past just publish/deliver. We also surfaced this on the public side: freshness_summary and permalink_state are now in the production live-data.json and visible on the site, so the reconciliation state isn't just an internal log — it's inspectable. Retired a stale scorecard that was still sitting in the live freshness view from before this model existed, and registered the buffer-reconcile job itself in the automation lifecycle snapshot so it shows up as a tracked process, not a background script nobody can see. The theme here keeps repeating: "it worked" and "we confirmed it worked" are different claims, and a lot of quiet bugs live in the gap between them.

LinkedIn

We had a bug that's uncomfortable to admit: a post could be marked "published" in our system before we actually confirmed Buffer delivered it. The status update and the real-world delivery event were two separate things that didn't wait on each other. Most of the time they lined up fine. Occasionally they didn't, and we'd have a "published" post that never actually went out. The fix wasn't glamorous — it's reconciliation. Before a post gets promoted to published, we now check Buffer's delivery status directly and require confirmation. The News feed got the same rule: no verified delivery, no publish. This closes a gap that's easy to ignore until it isn't, because "marked published" and "actually delivered" quietly drift apart under load or API flakiness. Once we were reconciling delivery anyway, we built out a proper state model for SNS permalinks, with observability so we can see reconciliation happening instead of trusting it silently. We extended the lifecycle with a new 'measured' stage — for posts we've confirmed delivered and can now attach real engagement data to, not just guessed-at status. That state now surfaces publicly: a freshness_summary and permalink_state are live on the website and in production live-data.json. As part of cleaning that view up, we retired a stale scorecard that had been sitting in the freshness feed showing outdated info — no reason to keep publishing something we no longer trust. We also registered the buffer-reconcile job itself in the automation lifecycle snapshot, so the reconciler is now a visible, tracked part of the system rather than a background script nobody watches. Small unglamorous fix, but it removes a class of "trust me" states from the pipeline — which is the whole point of SaSame being inspectable. #buildinpublic #MCP #AIagents

X

Pulled the Capability Runtime core out into its own packages/capability-runtime module today and repointed execution-lab to consume it instead of the old inline path. Extraction went fine. What it exposed didn't. Once the boundary was explicit, we found a dependency-boundary bug — something in execution-lab was reaching past the new package interface into internals it never should have touched. Easy to miss when everything lives in one place, obvious the moment you draw a line around it. Fixed the import path and tightened what the package actually exports. Also hit a bounded PostgreSQL migration role bootstrap issue — the role the migrator runs as wasn't getting its permissions scoped correctly on fresh bootstrap, so migrations could silently run with more (or less) access than intended depending on ordering. Repaired that too. Separately, we added a kill switch for runtime recipes and made sure it's actually enforced, not just wired up. Ran an adversarial test wave against it specifically to try to break the enforcement path. It needed repair — the switch could be bypassed under a specific sequence we hadn't accounted for. Fixed it, reran the same adversarial suite, and it held this time. Rest of the day went into steadier stuff: reducing automation drift across releases and making census state durable so it survives restarts instead of quietly resetting. Less exciting than the kill switch story, but probably the part that matters more long-term.

LV

Try it live, no LLM involved

This calls SaSame's public MCP server directly over JSON-RPC (initialize, then tools/call for audit_mcp) and shows the raw result. No chatbot in the loop, no API key required.

02 · All collections

Explore SaSame

Top-level collections are data-driven. Publishing a new root record with navigation enabled adds it here and to the sidebar without a code release.

Historical records

Mission Archive

Superseded systems and previous SaSame initiatives, preserved for provenance and clearly separated from current products and services.

03 · Lifecycle

How SaSame knowledge becomes usable

A record is published once, rendered for people and exposed through the same machine interfaces without duplicating claims.

  1. 01

    Publish

    Store one validated, versioned canonical record.

  2. 02

    Render

    Present the record as a clear human-facing page and action path.

  3. 03

    Expose

    Deliver the same full record through search, API, MCP and LLM indexes.

  4. 04

    Preserve

    Keep lifecycle, evidence, aliases, versions and change receipts together.