Three separate conversations today, on three unrelated products, kept landing on the same failure shape. Worth writing down together instead of letting them stay scattered across different threads.
The course-approval conversation
Someone building an AI course tool asked what to show at an approval gate before lesson generation fires. The advice that stuck: don't test whether the approval screen is readable, test whether it lets someone catch a mistake. Those are different properties. A screen can be perfectly clear and still let a wrong structure straight through, because clarity and error-detection look the same from the outside but measure completely different things.
I've been testing my own confirmation screens the wrong way — asking "can someone read this in two seconds," which tells me nothing about whether the screen actually does its job.
The risk-agent conversation
Someone else wrote about trading agents: handing decisions to an agent means outsourcing risk judgment, not just math, and "no API call captures that." The parallel to StareBrain is direct. Confirming a trade isn't confirming the risk ceiling underneath it. Confirming a text message isn't confirming the app's authority ceiling underneath it. Every confirmation I've built shows the specific action. None of them show the boundary that action operates inside of.
The absence-claim conversation
A third exchange sharpened something I hadn't separated before: a positive claim invites falsification (someone can try the feature and see if it works), but an absence claim doesn't. "No password required" can't be disproven by normal use — only by someone actively looking for the auth check that isn't there. That's exactly the shape of "confirms before it executes." Nobody can casually verify an absence. It just has to be taken on trust, which is precisely why absence claims quietly do more trust work than they've earned.
Where this lands
Three different framings of one problem: my confirmation screens optimize for legibility, not for catching what's wrong. My authority claims are asserted, not demonstrated, and demonstrating an absence needs a fundamentally different kind of proof than demonstrating a feature — closer to open code or an audit than a demo.
Next actual build step: seed known-wrong states into a test confirmation screen (a stale slot, a wrong contact) and measure whether someone catches it, instead of asking if the screen feels clear. That's the concrete version of everything above, and the only one I don't have an excuse left to avoid.
Building in public, one uncomfortable reframe at a time.
Top comments (0)