StareBrain

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.

Building StareBrain — say a command in plain English, see exactly what it's about to do, confirm before anything runs. Follow-up to last week's build log, because someone gave me a model that broke a fix I thought was already solid.

My system had two states: executed, or blocked. Turns out blocked was doing more work than it earned. My earlier fix — tag every attempt with an ID, drop stale results that don't match — stops the interface from showing a wrong result. It does nothing to revoke the authority of an older, already-in-flight attempt to actually go complete somewhere downstream I'm not watching. Fixing what the screen says isn't the same as fixing what happened.

The real model needs three states, not two:

• EXECUTED — observed evidence of the actual side effect

• DENIED_CONFIRMED — denied, and verified it never crossed the execution boundary

• DENIED_UNRESOLVED — denied, but downstream state can't be conclusively closed

That third one is uncomfortable, because for some actions it might be permanent. I can't query someone's phone to prove a text never arrived. The most honest claim I can make is "never submitted to the provider" — narrower and weaker than "not delivered," but true.

Also landed on a reframe today that's changing how the confirmation screen itself reads: once something's crossed the boundary where consequences aren't fully yours to control anymore, undo stops being reversal and becomes recovery. Reversal means the event un-happens. Recovery means you're managing the aftermath as well as you can. A confirmation screen's real job might be telling you which one you're about to sign up for, before you tap confirm.

Slower week than expected, in a good way — more time spent finding gaps in fixes I thought were done than writing new code.

Building in public as I go — waitlist link in profile if you want to follow along.

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.

Building StareBrain — say a command in plain English, see exactly what it's about to do, confirm before anything runs. The hard part was never parsing the command. It's designing the confirmation screen itself.

My first instinct was to sort actions by category and give "sensitive" ones (messaging, calls) more scrutiny than others (wifi, app launching). Got pushed on this in a thread this week, and the reframe stuck: the real split isn't risk, it's recoverability. Toggling wifi and moving a calendar event with notice are both trivially reversible. Sending a text or placing a call isn't — there's no unsend on a message someone's already read, regardless of how "risky" typing it felt.

That test holds up better than risk ever did, because the two come apart constantly. A scary-sounding action can be fully reversible. A boring one can't be undone at all.

So the confirmation screen is changing: low-stakes, reversible steps collapse into one compact plan. Anything irreversible gets its own explicit line, even if that makes the screen longer. Betting that costs a second of reading time and buys real trust.

Building in public as I go — link in profile if you want to follow along.

Building a natural-language command app for Android — say something, get a plain-English confirmation, approve it, it executes. The pitch is "nothing happens without your say-so."

Except I hit a gap: the world can change in the seconds between confirmation and execution. User approves "book 2pm with John," but by the time it fires, that slot's gone. Or approves a text to "Sarah," but Sarah's number just changed. The confirmation was correct when shown — it's stale by the time it runs.

Right now the fix is naive: re-check whatever the action actually depends on immediately before firing, and if something material shifted, don't silently proceed — kick it back to the user instead of guessing that the new state still matches their intent.

Curious how others building confirm-before-execute or agentic flows handle that gap. Do you re-validate right before the action, treat it as a transaction with rollback, or just accept the small window and move on?

Uploaded the first video to StareBrain's YouTube channel this week (@starebrain), a short demo of the say-it-confirm-it-happens flow.

Also had two genuinely useful exchanges on Indie Hackers that are shaping the confirmation logic directly. One: verification and the report of what was verified aren't separable, a system can't claim "I couldn't confirm this" credibly unless something real actually tried to check first. Two: testing whether sample agreement across repeated model attempts can distinguish genuine ambiguity from ordinary hedging, before deciding whether to ask a clarifying question or just proceed.

Both are going into how StareBrain decides when to show a confirmation versus ask a follow-up question, rather than treating that as a fixed rule.

Small week technically, but the confirmation step is the whole bet here, so getting it right matters more than shipping new commands right now.

A conversation this week pushed me to test something I hadn't considered: instead of only building toward the full app, publish the interpretation logic itself, real example commands and the exact structured plan StareBrain would generate for each one. No app required to see it.

The idea is to test whether the core value (understanding what someone actually wants, clearly, before anything executes) is interesting on its own, before the harder app-shaped problems (permissions, reliability, on-device execution) are fully solved.

Also set up a YouTube channel this week (@StareBrain) to start sharing the real app running, not just screenshots. First real upload coming soon.

Small, unglamorous week of testing ideas rather than big news, but that's honestly most of what building this actually looks like.

StareBrain started as a personal annoyance: tapping through five screens on my phone for things I already knew exactly how to describe in one sentence.

Currently pre-launch, waitlist open. The core mechanic is simple: say what you want done, see exactly what StareBrain is about to do, then it executes only once you confirm. Most AI assistants either act too autonomously or bury confirmation behind assumptions you never see, this flips that.

Been building in public for the past few weeks, real conversations, real feedback, real mistakes along the way (including a demo video that got 19 views and zero engagement, which was more useful than it sounds). Posting updates here as things progress.

If you want to follow along or try it early: starebrain.vercel.app