Make approval specific, current, and enforceable

“Looks good” needs a precise object

Before a consequential action, the user should see the exact item, quantity, total, destination context, and relevant conditions. Approval must refer to that proposal, not a vague earlier conversation.

Bind approval to a cart version. If the price, item, quantity, or destination changes, invalidate approval and ask for review again. In a live system, recheck time-sensitive facts before acting.

Check your understanding

A new quote raises the total after approval. What should happen?

Enforce the gate in the action path

A disabled button helps the interface, but the action handler must independently reject an unapproved proposal. The lab checks the version at submission time and keeps a logical operation ID for duplicate prevention.

Our simulation demonstrates these invariants locally. In production, enforce them on the server with authenticated ownership and durable records. Client-side state is editable and cannot be the final authority for a real purchase.

Check your understanding

Show a clear outcome and a way to stop

After simulation submission, show a simulation receipt. If the response is uncertain, say so and reconcile the existing attempt. Do not call an unconfirmed action successful.

The Safety Lab combines a stale approval test, a price-change test, and a duplicate attempt. Your checkpoint is to explain why each is blocked or deduplicated. There is no live purchase connection.

Check your understanding

What information should be visible at approval time?

Key takeaways

• Show the exact proposal before approval.
• Recheck permission inside the action path.
• Treat changes and uncertain outcomes explicitly.