Approval workflows

When OpenFeather prepares an action, the workflow shows what would happen, against which account, with which content. You approve or reject it. A rejected action produces no external change and no cost for the execution it never performed.

• Low risk — read-only or internal preparation, such as drafting a message for review.
• Elevated risk — anything that leaves OpenbirdAI or consumes a provider capability.
• Not permitted — actions the product will not perform regardless of approval.

1. 1Make the prepared action easy to read in full — do not truncate the content you are approving.
2. 2Show the target account explicitly.
3. 3Require approval for every external action, even in an automated run.
4. 4Log the decision so you can audit it later.

• Provider-side actions you take outside OpenbirdAI.
• Actions performed by tools you configured elsewhere.
• The accuracy of the reasoning that led to the action — approval is your judgement about the plan, not a guarantee of the outcome.

• The complete content of the action, not a truncated preview.
• The exact account or destination it would affect.
• What will be sent, created or changed, in plain language.
• Whether anything irreversible is involved.

If any of those are missing, do not approve. An approval you cannot fully read is not an approval.

Approvals are only useful if someone looks at them. Once a workflow is trusted, approvals become rubber stamps and the checkpoint stops doing its job.

1. 1Review recent approvals monthly at the start.
2. 2Ask for each approved action to be justified in one line.
3. 3Revoke standing approval for anything nobody remembers approving.
4. 4Tighten the workflow when the same wrong action keeps getting approved.