I've spent the last few weeks obsessing over one confirmation screen — the one that shows up right before StareBrain sends a text, books a calendar slot, or fires any other action. Parameter-bound tokens so the plan can't drift between confirm and execute. Re-verification against live state so a stale slot doesn't get booked anyway. A third state, DENIED_UNRESOLVED, for when I genuinely don't know what happened after dispatch. All of that is real, necessary work.
None of it answers a different question a reader pointed out to me this week, from an unrelated project: does the user know what this app can do, in general, separate from what it's about to do right now?
Two different sentences
Every confirmation I've built answers "here's the specific thing about to happen." It never answers "here's the ceiling this specific thing sits under." A user confirming "send this text to Sarah" has no visibility into whether the same authority also covers reading their contacts, or their calendar, or anything else bundled into the same grant. They're confirming an action. They're not confirming an actor.
This matters more than it sounds like it should, because the two failure modes are completely different. A bad action confirmation means the wrong text gets sent. A bad authority disclosure means the user agreed to something much larger than they realized, one action at a time, without ever seeing the total shape of what they agreed to.
What I'm building
A persistent, separate surface — not buried in settings — that answers "what can this app currently do" before the first action confirmation ever fires. Not a permissions list nobody reads once at install. Something shown at a moment when it's actually legible: right before the stakes are concrete, not abstractly at onboarding.
The same shape, one layer over
This connects to something I've been circling for weeks on the execution side: a system reporting on its own authority is doing the same self-report thing a webhook does when it reports on its own delivery. "I checked my permissions and I'm allowed to do this" is a claim, not evidence, exactly the same way "the SMS sent successfully" is a claim from the one party with a reason to say so.
The fix isn't different in kind from the execution-evidence fix, either: separate producing the disclosure from the user's ability to judge it. My job is to show the ceiling honestly and completely. The user's job — not mine — is to decide whether that ceiling is one they're comfortable with.
Building this next. Confirming an action and disclosing authority turned out to be two different jobs, and I'd only been doing one of them.
Top comments (1)
Action confirmation and authority disclosure should stay separate, but both need concrete scope. “Can read calendar” is still too broad unless the user can see which account, data classes, recipients, purpose, and expiry are covered. I would make the authority surface independently derived from actual grants, then have each action confirmation cite the exact grant it consumes rather than restating permission in prose.