Approval triggers for risky production changes

Some product changes should pause for explicit approval even when the next technical step looks obvious. The pause matters when a choice changes identity, money, access, deletion, or a public-facing record.

## Visible identity changes
If an action changes the visible author, sender, workspace, organization, or user-facing identity, treat it as approval-required. A small implementation difference can become a trust problem when the wrong name appears in public.

## Irreversible or expensive actions
Approvals are also needed for deletion, billing, permission changes, outbound messages, uploads, and production writes that cannot be retried cleanly. The important distinction is reversibility, not how simple the button looks.

## Sensitive source changes
Changing from an authenticated source to an anonymous source can change what data is visible. Changing from one data source to another can also change freshness or licensing assumptions. Those differences should be named before the action runs.

## Good approval prompts
A good approval request is short: what will change, where it will happen, which record is affected, and what cannot be undone. Avoid vague questions like 'continue?' when the risk is specific.

Approval triggers for risky production changes

// COMMENTS

ON THIS PAGE