# Approvals

> Review, approve or reject action plans in Vigilbase OS, propose remediation and follow an execution.

Source: https://docs.vigilbase.com/os/approvals

**Approvals** is where action plans wait for a decision. Nothing changes in your providers until an authorised member approves a plan here. Open it from the sidebar or press `g` then `a`; the sidebar shows how many plans are awaiting approval. You need the `action.read` permission to see it.

For the rules behind approvals, see [Approvals and policy](https://docs.vigilbase.com/os/concepts/approvals-and-policy).

## The queue

The queue shows plans **Awaiting approval** by default. Use the state filter to see other plans, for example **Approved**, **Verified**, **Rejected** or **Expired**. Columns are **Plan**, **State**, **Steps**, **Version**, **Expires** and **Proposed**. Plans with irreversible steps are marked **IRREVERSIBLE**.

## Review a plan

Open a plan to see:

- **Rationale**, including the expected benefits and the evidence
- **Steps**: each step's capability, effect class, provider, target, connection, the exact **Change** and its **Parameters**, any **Connector warnings (part of what you approve)** and its **Verification criteria**
- **Recovery plan**: recovery steps that run only if you include them, and only when their forward step fails or verification finds harm
- **Impact**: blast radius, prerequisites, protected resources, estimated cost, timing, expiry and policy version
- **Integrity**: the plan ID, version and SHA-256 hash
- **Approval history**: every decision, bound to the version and hash it was made against

Watch for these notices:

- **Resource drift detected**: the target changed since the plan was made. The plan will be superseded or re-validated rather than overwrite the change.
- **Kill switch engaged**: no approved action can execute until it is released.
- **Plan expired**: a new version must be proposed.
- **You cannot approve this plan**, with the reasons, for example separation of duties.

## Approve or reject

:::steps
1. **Go to Decision.** Choose **Jump to Decision**, or scroll to the **Decision** panel.
2. **Select the steps you approve.** Nothing is approved by default. Select a recovery step only after its forward step.
3. **Acknowledge irreversible steps.** If you selected any, tick the acknowledgement. Some steps also ask you to type a value, such as a zone name, to confirm.
4. **Add a comment if you want.**
5. **Choose Approve selected or Reject.**
6. **Confirm it's you.** Enter a code from your authenticator in the Vigilbase Identity window. A confirmation stays valid for an hour.
:::

The decision is bound to the plan version and hash shown at the bottom of the panel. If the plan changes while you review it, the latest version is shown and you must review it again.

To stop a plan before it runs, choose **Cancel plan**. You need the `action.cancel` permission. Cancelled plans cannot be approved or executed.

## Propose a plan

You need the `action.propose` permission. Start from a case with **Propose plan**, or choose **Propose remediation** on the Approvals page.

:::steps
1. **Choose the investigation.** Every remediation plan belongs to a case and cites its evidence.
2. **Give it a Plan title and a Rationale.** Explain the evidence and the intended security benefit.
3. **Add steps.** For each step choose a **Connection** with response access, a **Capability** and the target. Use **Add forward step** for more steps and **Add recovery branch** for a recovery step.
4. **Check the Live draft.** Vigilbase reads the current provider state and shows the exact changes, the blast radius and the verification criteria.
5. **Choose Propose plan.** The plan and its hash are stored and wait for an approver.
:::

## Follow an execution

After approval, **Execution and verification** on the plan links to the execution. The execution page is an immutable record:

- the state of each step, with the number of attempts, provider request and job IDs, and the provider state before and after
- **Outcome unknown** when Vigilbase cannot yet tell whether a provider accepted a change; the step is never blindly retried while the provider state is reconciled
- **Execution halted**, with the reason, for example when a kill switch is engaged
- **Verification**: each run's outcome and its three layers, **Configuration persisted**, **Security effect observed** and **Operational guardrails**

See [Verification](https://docs.vigilbase.com/os/concepts/verification) for what each outcome means.