> ## Documentation Index > Fetch the complete documentation index at: https://docs.get-hive.ai/llms.txt > Use this file to discover all available pages before exploring further. # Approvals before automation > How to design AI approvals people can decide in seconds: blast radius, reversibility, exact-parameter binding, expiry, and letting a denial teach the system. 17 September 2026 · The Hive team Most conversations about AI automation jump straight to the end state: the agent that just does it. We think the more important design problem is the step before — the approval. Get approvals right and automation follows naturally, one proven action at a time. Get them wrong and people either rubber-stamp everything or stop using the system. A good approval has one job: let the accountable person make a correct decision in seconds. Here is what that takes. ## Know what could go wrong: blast radius Not every action deserves the same scrutiny. Writing a draft nobody has seen is harmless; issuing a refund is not. If your approval flow treats them the same, it will be too slow for the first and too casual for the second. Hive gives every action a **blast radius** tier: | Tier | Meaning | Example | | - | - | - | | B0 | Invisible or reversible | update a fact, write a draft | | B1 | Internal-facing | post in Slack, create a task | | B2 | External, cheap to fix | email a known contact | | B3 | External, hard to reverse | message a VIP, send in bulk | | B4 | Money, legal or irreversible | issue a refund, revoke access | The tier decides who can approve and whether anything can ever skip approval. An Operator can approve up to B2, a Department lead up to B3, and only Owners and Admins can approve B4. B4 and irreversible actions always need a person. See [Autonomy and blast radius](/approvals/autonomy-and-blast-radius). ## Know whether it can be undone: reversibility Blast radius asks how bad a mistake would be. Reversibility asks whether you can take it back. Hive sorts actions into three groups with a simple test — could you undo it within five minutes? * **Reversible** — drafts, internal notes, document edits. Undo restores the previous state. * **Compensatable** — a sent message, a paused campaign. You cannot unsend, but a follow-up action can correct it. * **Irreversible** — refunds, charges, revoked access, deletions. Anything Hive does not recognise is treated as irreversible by default. Reversible actions can move faster because the [Audit log](/approvals/audit-log) offers one-click undo. Irreversible ones never run without a person. ## Show exactly what will happen The fastest way to slow approvals down is to make the approver reconstruct the action in their head. An approval screen should answer four questions without scrolling: 1. **What happens next?** The steps, in order, each marked "runs when you approve" or "runs automatically". 2. **What exactly will be sent?** The actual message, the actual recipient, the actual amount — not a summary. 3. **Why is this asking first?** The blast radius, how confident Hive is it can roll back, and the evidence behind the proposal. 4. **What if I do nothing?** Declining is a real option and deserves its consequences spelled out. Hive's review panel is built around those sections — **What happens next**, **Proposed message**, and **Risk and evidence** — with three buttons: **Approve & run now**, **Decide later** and **Do not run**. See [Review and approve](/approvals/review-and-approve). ## Approve the exact action, not the idea A subtle but important property: an approval should cover precisely what the approver saw. If the recipient, amount or content changes between approval and execution — because a model regenerated the draft, or because something upstream updated — the approval should no longer apply. Hive binds every approval to a hash of the exact parameters, and approvals expire after seven days. Stale approvals are a quiet risk in any system: the situation that justified the action last month may not hold today. It also means drafts are not edited inside the approval. If a proposal is not right, you decline it and ask for a replacement, so what runs is always what someone approved. ## Keep the approver honest about their authority When an action is above your role's ceiling, the screen should say so and route it, not hide it. In Hive, a proposal above your access says it "routes to" the role that can approve it, and read-only Analysts can see exactly why Hive proposed something without being able to act. Visibility and authority are separate on purpose: more people understanding a decision is good; more people able to make it is not. ## Let a denial teach A "Do not run" should not be a dead end. In Hive, a denial records an exception so that shape of action is not auto-run, and dismissals on signals ask why, so the next proposal is better. Approvals, in turn, are the evidence for promotion: when your team approves the same kind of suggestion three times within 30 days, Hive offers to automate it — starting in shadow, and capped below full autonomy. That is how approvals turn into automation without anyone taking a leap of faith. We wrote more about this in [Earned autonomy](/blog/earned-autonomy). ## And keep a way to stop Finally, any system that can act needs a single way to stop acting. Hive's kill switch halts every autonomous action and approval across the workspace, survives restarts, and puts learned automation rules back into shadow. Decide in advance who can press it. See [Safety and control](/admin/safety-and-control). ## The takeaway Automation is a sequence of approvals that went well. Design the approval — risk-aware, reversible where possible, exact, expiring and teachable — and you will have the evidence you need to automate the routine work, and the confidence to keep a person on the rest. The approval panel, section by section. Receipts, the reasoning chain and undo.