# Verification

> How Vigilbase OS checks that an approved change persisted, had its intended security effect and caused no harm.

Source: https://docs.vigilbase.com/os/concepts/verification

A successful API response does not prove that a fix worked. After an approved plan runs, Vigilbase OS verifies each step against criteria that were fixed when the plan was proposed and that the approver saw before approving.

## Three layers

Each verification run checks three layers:

| Layer | Question |
|---|---|
| **Configuration persisted** | Is the change actually in place when Vigilbase reads the provider back? |
| **Security effect observed** | Did the change have the intended effect, for example blocked requests attributed to a new WAF rule? |
| **Operational guardrails** | Did service health stay acceptable, for example the edge error rate compared with a baseline? |

The plan sets the observation window, baseline period, minimum sample size and success and failure thresholds for each step. You see them under **Verification criteria** on the plan before you approve.

## Outcomes

| Outcome | Meaning |
|---|---|
| **Pending** | Verification is scheduled or the observation window is still open. |
| **Verified** | The change persisted, had its intended effect and stayed within guardrails. |
| **Failed** | The change did not persist or did not have its intended effect. |
| **Harmful** | The change caused a problem that the guardrails detected. |
| **Inconclusive** | There was not enough evidence, for example no traffic or a disconnected feed. |

No traffic and missing telemetry always give **Inconclusive**, never **Verified**.

## When something goes wrong

- **Recovery steps** run only if the approver included them when approving, and only when the forward step fails or verification finds harm. Any other recovery change goes back through approval.
- **Unknown outcomes** are never blindly retried. If Vigilbase cannot tell whether a provider accepted a change, the step shows **Unknown** while Vigilbase reconciles the provider's actual state.
- **Partial success** is recorded per step. Changes across several providers are not atomic, so a plan can end **Partially succeeded**, and only approved recovery steps may run.

Each execution is an immutable record with the provider state before and after each step. See [Approvals](https://docs.vigilbase.com/os/approvals#follow-an-execution).