> For the complete documentation index, see [llms.txt](https://docs.aviator.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aviator.co/verify/concepts/verification-layers.md).

# Verification layers

A verification run is built from two sources of acceptance criteria: criteria the **submitter** (you or your agent) supplied for *this* change, and criteria the **team** encoded as invariants that apply to *every* matching change. Both flow through the same pipeline. This page is about how the two layers interact at run time.

For the deeper concept of invariants themselves, see [Invariants](/verify/concepts/invariants.md). For the pipeline, see [How verification works](/verify/concepts/how-verification-works.md).

### The two layers

| Layer                  | Where it comes from                                                        | Scope                  | Materialized as                                                  |
| ---------------------- | -------------------------------------------------------------------------- | ---------------------- | ---------------------------------------------------------------- |
| **User criteria**      | The MCP submission. Generated by the agent from the spec, or hand-written. | This change only.      | Acceptance criteria, source: `generated`, `parsed`, or `manual`. |
| **Invariant criteria** | The team's invariant catalog. Picked per-runbook by the selector.          | Every matching change. | Acceptance criteria, source: `baseline_invariant`.               |

The selector is what makes invariants *apply*. When a runbook is created, the selector reads the intent, the user criteria, and the change set, and picks which active invariants to materialize as criteria on this runbook. See [Invariants — How invariants apply to a runbook](/verify/concepts/invariants.md#how-invariants-apply-to-a-runbook).

The result: a single list of acceptance criteria with mixed sources. Verify doesn't distinguish at run time — every criterion goes through the same classifier and verifier path.

### How the layers combine

When verification starts, Aviator assembles the criterion set:

1. **Every user criterion** runs. Each one is routed through the verifier pipeline.
2. **Every invariant-materialized criterion** runs. Same pipeline, same verdict shape.

The two sets are concatenated. A typical run has 3–7 user criteria and a handful of invariant criteria. Both produce verdicts with evidence in the same review document.

A run passes only when every criterion passes (or is waived). Failures don't collapse — three failing criteria produce three verdicts, not one.

### Why two layers instead of one

You could push everything into user criteria: have the agent emit "requires authentication" on every submission. It would technically work, but it's the wrong factoring:

* The agent would have to remember the team's full ruleset on every submission.
* A bad submission could silently omit a rule.
* Changes to the ruleset would require re-instructing the agent.

Invariants live outside the per-submission loop. The team encodes them once. They apply automatically. The submitter doesn't need to know — the selector loads the matching set itself.

The mirror argument applies to user criteria: not everything can be an invariant. "This endpoint returns these fields" is specific to a change. Forcing it into an invariant would either bloat the catalog or push too much per-change content into team policy.

The split is: invariants for what's true across changes, user criteria for what's specific to this one.

### What the reviewer sees

In the review document, every criterion shows the same things: text, verdict, verifier, evidence. The only visible difference is a small tag indicating whether the criterion came from user input or from an invariant.

Reviewers can:

* **Approve** when every criterion passes.
* **Waive an invariant verdict** with a reason and a category (see [Invariants — Waivers](/verify/concepts/invariants.md#waivers)).
* **Edit user criteria** through the agent (via `editRunbook` on the MCP) when the wrong criteria were generated.

Invariant criteria can't be edited per-runbook. They're auto-managed by the catalog; if a rule is wrong, fix the invariant itself.

### When to put a check in each layer

| Use…          | When the check is…                                                         |
| ------------- | -------------------------------------------------------------------------- |
| User criteria | Specific to this change. Won't apply elsewhere.                            |
| Invariant     | Recurring. You'd ask the agent to assert it on multiple unrelated changes. |

The test for promoting a check to an invariant is recurrence: if you'd write the same criterion text on the next ten submissions, it should be an invariant.

### See also

* [Invariants](/verify/concepts/invariants.md) — deep concept page
* [How verification works](/verify/concepts/how-verification-works.md) — the per-check pipeline
* [Setting up org invariants](/verify/setting-up-org-invariants.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.aviator.co/verify/concepts/verification-layers.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.