2
1 Comment

StareBrain build log: "denied" and "verified not to have happened" are different claims

Spent the week refining confirm-before-execute UX — first reframing risk as recoverability, then recoverability as "how far did the consequence already travel before undo." Today got pushed on something sharper: my system only tracks two states, blocked and executed. There's a third I've been quietly skipping.

Got a framework for it that broke a bug fix I thought was already solved. Last week I found a race condition where a stale result from an earlier attempt rendered as "executed" right after the current attempt correctly denied. My fix: tag every attempt with an ID, drop stale results that don't match. Bug gone, or so I thought.

The gap: my denial log says "blocked," and that's true about the decision. It says nothing about whether the target system actually stayed clean. I check that the new attempt doesn't fire wrong. I never independently verify nothing landed from an old one — I just trust the stale-drop was enough.

Real model needs three separate guarantees, not one: the denied attempt never crosses the execution boundary, any earlier in-flight attempt gets cancelled or fenced off, and — the one I'm missing — independent verification that no side effect actually occurred downstream. If you can't prove all three, the honest verdict isn't "blocked." It's "insufficient evidence."

For something like a sent text, that third check might never fully close — I can't query someone's phone to confirm a message didn't arrive. So "insufficient evidence" may end up a permanent state for certain actions, not a temporary one I eventually resolve.

Also ran a real test today instead of just theorizing: pulled a dependency-invalidation library, wrote the stale-booking scenario myself, ran it in a clean environment. It blocked correctly. First thing all week I verified instead of took on faith.

Building in public, mistakes and all — link in profile if you want to follow along.

posted toAvatar for product StareBrain
StareBrain
  1. 1
    This distinction feels especially important in protection systems: a system can know what decision it made without necessarily knowing what happened downstream. I've run into a similar design question while working on safeguards for a software system. It changed how I think about status messages: "denied" describes the decision, while "no side effect occurred" is a much stronger claim that requires evidence. That makes "insufficient evidence" a surprisingly valuable state. It prevents the protection layer from turning uncertainty into false reassurance.