Pattern 29
Suggest, confirm and act
Separate a generated proposal from a real change.
Concrete takeaway
Show the exact proposed change and its scope before executing an action that needs approval.
Choose an approach
These are editorial decision conditions to validate. Some alternatives are successive states or can be combined; they are not always exclusive choices.
| Alternative | Use when | Tradeoff or requirement |
|---|---|---|
| A · Proposal | The assistant proposes an action | A suggestion is not permission to execute |
| B · Review an action | An action affects saved or shared material | Review must name the consequence and recipient |
| C · Result and recovery | An action completed or failed | Show actual results and recovery rather than a generic success message |
The problem
“Make a reading plan” may mean draft one, save it, schedule reminders or share it with a group. Those are different consequences.
The pattern
Show the exact proposed change and its scope before executing an action that needs approval. Separate saving, scheduling and sharing. Respect bounded standing permissions and show actual success, failure and available undo.
Compare the alternatives
Separate a generated proposal from a real change.
A · Proposal
Drafting has no hidden external effect.
B · Review an action
Audience and side effects are concrete.
C · Result and recovery
The actual outcome closes the action.
Original wireframe proposals · No live controls · Grey rows represent schematic text, not loading states · Labelled placeholders are not Scripture quotations
Download this wireframe as SVGFailure modes
A request to reflect becomes a shared prayer; a global autopilot permission; duplicate reminders after a retry; a success message before the action succeeds.
What to validate
Can users predict the effect before confirming? Test cancellation, revoked permission, partial failure and retry without duplicate changes.
Research-informed design proposal. These visual alternatives have not been tested with users in this atlas. Source findings, documented behaviour and this proposed adaptation are different kinds of evidence.
Sources and adaptation
This card is an original design synthesis. The following sources inform its content distinctions, interaction approach or review requirements; they do not validate the whole pattern.
- Suggest Confirm ExecutePattern detail reviewed · Approval thresholds depend on consequence and previously granted permissions.
- Control the level of automationPattern detail reviewed · Standing authority must be bounded and revocable.
- Agentic UX PatternsPublished catalogue overview and example reviewed · The catalogue presents 49 proposals. Their inclusion is not evidence of effectiveness in faith or clinical settings.
- AI Interaction AtlasOfficial repository and taxonomy reviewed · A taxonomy, not a prescriptive UI framework. The official repository is available at https://github.com/quietloudlab/ai-interaction-atlas under Apache 2.0.
Common scenarios and flows
- Prepare and participate in an AI-assisted practice — Use bounded adaptation while keeping Scripture, authorship and user choice inspectable.
- Prepare teaching with accountable evidence — Build an explanation that another person can inspect, without outsourcing interpretive responsibility.
Design principles in this decision
Editorial application of Missional by Design. These values frame review questions; they do not validate a pattern’s effectiveness.
- Reverence — What does this interaction ask of the person, and can they understand, decline, correct or leave it without penalty?
Compare alternatives using the task and evidence above. Record competing needs instead of treating a principle as an automatic verdict.