Building StareBrain — say a command in plain English, see exactly what it's about to do, confirm before anything runs. Been refining the confirmation model all week: risk → recoverability → how far did the consequence travel. Today's push sharpened it into something I can actually build against instead of reason about.
The distinction: capability is a static fact about an action type — can it, in principle, ever reach someone else. A wifi toggle can't. A sent SMS always can, by definition, no matter how it's implemented. State is a dynamic fact about one specific attempt — did this run actually reach the tier its capability allows.
Why this matters: it means the expensive part (tracking uncertain state, handling "we don't know") only has to happen for actions whose capability tier permits leaving your own boundary in the first place. A wifi toggle's unknown state is trivial — there's no boundary to have crossed even if you don't know. A sent SMS's unknown state is real, because its capability was always "can reach someone else." Capability sets the ceiling on how much an unknown state can matter. Tag actions by capability up front, and "unknown" stops being the default answer for everything.
Also converged on the actual event-record shape today, pulled from a few different threads: not a status word, but last-confirmed-stage, an evidence ID where one exists, a timestamp, and an explicit "what remains unknowable" field. That last one's the piece most systems skip — making the gap itself a first-class field instead of an implicit silence, which is what stops "we don't know" from quietly decaying into "nothing happened" over time.
One more rule I'm now enforcing rather than leaving as an accident of code path: only UNRESOLVED gets retried. A confirmed DENIED never does. Obvious once stated, but I don't think my system was actually enforcing that as a rule before today.
Building in public as I go — waitlist link in profile if you want to follow along.