Someone actually broke my stale-plan protection on purpose, and it worked
Been going back and forth for a few weeks with someone in the comments here about the confirm-then-execute gap in StareBrain — a user approves an action, then the underlying state changes before it actually fires. A booked slot fills. A contact updates. The plan you approved isn't the plan that runs.
This week someone (ibd, from an earlier thread) actually built the test instead of just discussing it. Small deliberate setup: plan a booking from an available slot, then flip that slot to unavailable before dispatch. Run it two ways — once with a validation boundary in front of the action, once without.
Without the check: one booking effect. The stale plan executed anyway.
With the check: blocked, zero effects, flagged as stale reasoning.
It's a filesystem fixture, not StareBrain's real code and not a calendar provider — small and artificial on purpose, so the only thing being tested is whether the boundary actually catches a deliberately staled plan. It did.
Next step is the same shape against a real StareBrain action instead of a fixture. Posting this because it's the first time this specific failure mode went from "thing I keep describing" to "thing that was made to happen and then blocked, on purpose, with a receipt."
Love this angle, honestly. What made you look into it in the first place?
Helpful post. How did you get your first bit of traction?
Solid lesson. Which channel has worked best for you so far?
Nice progress. What is the next thing you are focusing on?
Clear and practical, thanks. Did anything surprise you along the way?
This is a really clean test.
The zero-effect result with the validation boundary is especially useful because it proves something quite specific: the stale plan was stopped before the action crossed the boundary.
I’d be curious about the next version against the real action.
If validation passes, the action is dispatched, but the downstream system gives you an ambiguous result, how does StareBrain represent that?
That feels like the other half of the problem: stale authority before dispatch vs unresolved consequence after dispatch. In the second case, retrying could itself become the dangerous action.
Really interested to see what happens when you run this against the real boundary.
That's the harder half, and I don't have it solved yet. Right now StareBrain doesn't have a clean answer for "dispatched, but the result came back ambiguous" — it's sitting in the same bucket you'd expect: don't assume success, don't blindly retry (since retry can itself be the dangerous action if the first attempt actually landed), and don't just leave it silently pending either. The honest current state is a flagged, unresolved status that needs a human decision rather than an automatic one, but I haven't built out what that flow actually looks like end to end. FreshCtx solves the before-dispatch half; the after-dispatch half is the next real problem, not a solved one.
That’s exactly the boundary I was trying to locate.
What you’ve described as the unsolved half is essentially where OpsWatch starts: once dispatch has occurred, if the consequence cannot be established, I preserve that as DENIED_UNRESOLVED rather than converting uncertainty into success, failure, or an automatic retry.
The retry point is particularly important. Once the first attempt may have produced the consequence, a second attempt is no longer just recovery logic — it can be a new consequential action requiring fresh authority.
So this actually suggests FreshCtx and OpsWatch may sit on opposite sides of a very clean seam rather than competing for the same control surface.
I’d be interested in testing that seam against one concrete StareBrain workflow: FreshCtx governs the pre-dispatch side, then we see whether OpsWatch can take the post-dispatch evidence boundary without either system having to reinterpret the other.
That seam description matches how I'd want to think about it too — FreshCtx answering "is the authority still valid right now" and OpsWatch answering "what actually happened after we acted on it," without either one needing to model the other's internal state.
To make the test concrete: the workflow I'd propose is the SMS send action, since it's the simplest case with a real ambiguous-failure mode (request sent, network drops before the delivery acknowledgment comes back). FreshCtx would gate the send on current authority (permission still granted, right contact); if that passes and the send dispatches, the open question is what evidence OpsWatch needs from my side to make the DENIED_UNRESOLVED call correctly, versus what it can determine on its own from the dispatch attempt.
Concretely: does OpsWatch need me to tell it "I don't know if this landed," or can it infer that from a timeout/missing-ack pattern without StareBrain having to self-report the ambiguity? That distinction decides how tightly coupled the two systems end up being at the seam.
Happy to actually build this test rather than just discuss it — what would you need from my side to run it against the SMS case specifically?
Manan — yes, let’s make this concrete.
The distinction you’ve drawn is exactly the one I’d want the test to preserve. OpsWatch shouldn’t require StareBrain to declare “I don’t know if this landed” if the permitted evidence itself is insufficient to establish the downstream consequence. Otherwise we’ve made the system under test responsible for reporting the uncertainty the independent boundary is supposed to determine.
For the SMS case, I’d want to freeze the attempt identity, authority state at execution, dispatch evidence, and exactly what downstream evidence OpsWatch is permitted to consider. Then deliberately create the ambiguous window you described: dispatch occurs, but confirmation is unavailable or lost.
The interesting result isn’t whether we can manufacture a timeout. It’s whether OpsWatch can independently distinguish what is established from what remains unresolved without inheriting StareBrain’s interpretation of the attempt.
I’m happy to run this as an actual bounded test rather than keep discussing it in comments.
Email me at jason@mcgillintelligence.com.au and we can move the exact SMS workflow/evidence contract there.
Jason