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

Spent the last stretch on something that sounds simple and wasn't: making work resumable across worktrees and agents in owner-mcp. The core piece is a 6-part Task Inbox / Handoff Directive system. The idea is that a task shouldn't die just because the process handling it does — an agent working in one worktree needs to be able to hand off, and another agent (or a resumed instance of itself) needs to pick it up in the right context, with the right owner, without redoing work or stepping on a duplicate PR. Getting there meant fixing things we didn't expect to touch. Owner-scoped principal continuity was quietly wrong — a resumed task could lose track of whose authority it was acting under. We also had no real guard against duplicate PRs from parallel worktrees, so two agents could open the same PR twice if timing lined up badly. While building the Task Inbox we found and closed 3 owner-review gaps — cases where a handoff could slip past the owner-review step it was supposed to go through. Those are the kind of bugs that don't show up until something is actually running unattended, which is exactly the point of this system. We also added child-governance auto-bootstrap for worktree_task_open and worktree_task_resume, so a new or resumed worktree task inherits proper governance instead of starting ungoverned and needing manual setup. The gate for all of this wasn't a unit test — it was a real multi-process, cross-provider end-to-end run, actual separate processes and actual different providers talking to each other through the handoff path. That was the thing that had to pass before we'd call it done, because this is exactly the kind of system where mocks lie to you. Feels like the boring infrastructure work that everything else depends on later.

LinkedIn

Fixed a false-positive bug in capability-classify this week (#2327), and it's the kind of bug that's boring to describe and uncomfortable to have shipped. capability-classify is the piece of SaSame that decides whether an MCP capability call is state_changing before we gate it. Somewhere in the classifier there was a substring fallback — if nothing else matched, it would scan the tool description or schema for loose keyword hits and use that as a verdict. It was meant as a safety net for capabilities that didn't declare themselves clearly. The problem is a substring match has no boundaries. Any tool with "update," "delete," or similar language anywhere in its description — including in a comment, an example, or a negation like "does not delete anything" — could get flagged as state_changing. Unbounded means exactly that: no anchoring to intent, no anchoring to the actual operation, just "this string appears somewhere." In practice that produced false positives: read-only capabilities getting gated as if they wrote data. Annoying but safe-ish in that direction. The scarier failure mode is the inverse — a capability that genuinely mutates state but whose description happens to dodge the keyword list, sliding through unclassified or misclassified as safe. Same root cause, opposite consequence, and the second one is the one that actually matters for an inspection/observation registry whose whole job is knowing which calls are safe to run without asking. The fix removes the fallback entirely. If the classifier can't determine mutating intent from the structured signals it's supposed to use, it now returns unclassified instead of guessing, and unclassified gets handled explicitly upstream rather than silently defaulting to a keyword scan. Less clever, more honest about what we don't know yet. Nothing dramatic here — no incident, no bad write got through in production. Just found the fallback while auditing classify paths and didn't like how much it was papering over the fact that we didn't have a real signal. #buildinpublic #MCP #AIagents

X

Fixed a correctness bug in capability-classify today (#2327): an unbounded substring fallback that was producing false state_changing verdicts. The classifier decides whether an MCP capability call should be treated as mutating — this is what gates write operations before they hit anything real. The fallback logic was doing a loose substring match as a last resort when other signals didn't resolve cleanly, and it was too permissive. Calls that had nothing to do with mutation were getting flagged state_changing just because some substring happened to match. This kind of bug is annoying specifically because it's silent in both directions. Overclassifying as state_changing means read-only calls get gated like writes — friction with no benefit. But the scarier version is the inverse: if the fallback logic can produce false positives, the same shape of bug can produce false negatives, meaning a real write operation slips through unclassified as safe. We didn't find an instance of that here, but the unbounded substring approach was the kind of thing that could go either way depending on capability naming, so it needed to go regardless of which direction we'd actually observed the failure. Fix was to remove the fallback rather than tighten it — if the primary classification signals don't resolve, that's a case we want to know about, not paper over with a heuristic.

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.