SaSame

We ran an issue backlog convergence pass this week and the interesting part isn't the convergence, it's what we did when the duplicate heuristic wasn't sure. The orchestrator scores candidate duplicate issues against each other and merges when confidence is high. The question we had to answer up front was what happens in the ambiguous middle — two issues that look similar but not similar enough to auto-close with confidence. We decided to fail closed. If the heuristic can't clear its threshold, the issue stays open and gets flagged for review instead of getting merged. That means the backlog convergence effort is slower and leaves more "maybe duplicate" clutter sitting around than a more aggressive merge policy would. We're fine with that tradeoff. A silent wrong merge deletes context and nobody notices until someone goes looking for an issue that isn't there anymore. A backlog that's a little messier but honest is easier to fix later than one that's been quietly wrong. We tracked the whole pass through a single checkpoint so we could see the queue shrink (or not) over time, rather than trusting a one-shot "we merged N issues" claim. Closed the checkpoint once the backlog actually converged — no more auto-mergeable candidates left, only the flagged ambiguous ones sitting in review. Nothing dramatic here, just a policy choice we wanted on record: when in doubt, the orchestrator leaves the mess visible instead of cleaning it up wrong.

We spent today on something that sounds small but has been bugging us for a while: how information assets in SaSame get born in the first place. Up until now, asset creation was ad hoc. Something would get generated, get written somewhere, and only later would we retroactively figure out what state it was in, whether anything else was touching it, whether it was "final" or still in flux. That worked when there wasn't much to track. It stops working the moment more than one process can touch the same thing. So we built what we're calling a genesis information asset kernel — basically a defined starting point for any asset's lifecycle instead of assets just appearing wherever. Alongside it, we bound the workspace state to a lock. The point of the lock isn't performance, it's honesty: at any given moment there's one authoritative answer to "what is the current state of this workspace," not several half-true ones depending on which process you ask. The self-critical part: we should have had this from day one. Not having it wasn't a design decision, it was just deferred debt — easy to skip when there's only one thing happening at a time, expensive to skip once there isn't. Nothing dramatic to report yet, no metrics, just a foundation that now exists where before there was an assumption. Curious how long it holds before we find the first edge case that breaks the lock's assumptions.

Pancho's lineage broke, and fixing it taught us something about what "recovery" should actually mean. Short version: the Pancho agent's business lineage failed. The chain that was supposed to trace its history back through prior succession points was broken, which meant the orchestrator had no clean way to say "this is the continuation of that." Our first instinct was to reconstruct the lineage from scratch — rebuild the history, backfill the chain, make it look intact again. We didn't do that. Reconstruction assumes you can safely rewrite the past to match a clean model, and in a system where lineage is supposed to be a factual record, that felt wrong. If the chain broke, papering over it with a reconstructed version just hides where the actual discontinuity happened. Instead the orchestrator adopted a direct successor-resume model: rather than rebuilding history, it resumes forward from the last known-good state and treats the new agent as a direct successor from that point. The gap stays visible instead of getting smoothed out. The failover itself is now formally recorded as closed — not erased, just marked as a resolved event in the record. The distinction matters more than it sounds. A system that reconstructs lineage on failure is optimizing for looking continuous. A system that resumes from a successor point is optimizing for being honest about what actually happened, while still letting the agent keep going. We picked the second one, mostly because SaSame's whole premise is that the registry should be inspectable — and an inspectable history has to include its own breaks. Curious whether other people building agent orchestration have run into the same fork: patch the record, or record the patch.