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. For the pipeline, see How verification works.

The two layers

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.

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).

• 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

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 — deep concept page

• How verification works — the per-check pipeline

• Setting up org invariants