The decision
Confidence does not grant permission
A model can be likely to produce the right answer and still have no authority to act. It can also be uncertain about a low-consequence, reversible suggestion that costs little to inspect.
Approval belongs at the boundary between system capability and human authority. Four questions locate that boundary.
Four questions before the prompt
- Is the action authorized?Check role, policy, data scope, and the user's explicit instruction. A reliable output cannot override a missing permission.
- What follows if it is wrong? Separate a private draft from a payment, public message, legal commitment, or record change.
- Can the result be recovered? Undo works before an external consequence. After that, the product may need compensation, escalation, or repair.
- What evidence supports the decision? Use measured task reliability and source quality. Treat model-stated certainty as an unverified signal.
Working rule
Match control to consequence
Suggest when the result is easy to inspect and nothing changes until the user accepts it.
Prepare when the system can do useful work in a bounded draft without crossing an external boundary.
Ask before high-consequence, externally visible, or policy-sensitive actions.
Refuse or escalate when authorization is absent, policy is clear, or safe recovery does not exist.
Concrete example
Prepared coding is not an approved payment
An accounts-payable product may extract invoice fields and prepare coding from permitted sources. It should show provenance, preserve supplier conflicts, and let the reviewer correct the draft.
Approving, posting, or scheduling payment is a different action. The consequence and authority have changed, so the product asks for the required approval even when the prepared coding is strong.
Take this into a product review
Replace “How confident is the model?” with four columns: authorization, consequence, recovery, and evidence. Then decide whether each behavior suggests, prepares, asks, or refuses.