# Verification Domain

**Status:** Approved target-state baseline  
**Thin seam:** I1  
**Full activation:** I5.

## Target State

Verification is an independent authority. Coding/review agents may request or produce candidate evidence; they cannot unilaterally declare the work verified.

```text
ChangeSet + Task acceptance + policy
   ↓
VerificationAuthority
   ├─ ChangeClassifier
   ├─ VerificationPlanner
   ├─ VerificationAdmission
   ├─ EvidenceLedger
   ├─ EvidenceInvalidator
   └─ GateEvaluator
   ↓
TaskVerificationGate
ReviewVerificationGate
ChangeSetCompletionGate
MergeGate
ReleaseGate
DeploymentGate
```

## Core Primitives

### VerificationEvidence

Immutable-ish receipt of a check/proof bound to:

```text
property/invariant demonstrated
source/candidate identity
scope
check definition/version
relevant dependencies/config/environment/data identity
executor/provider
result
start/end
artifacts/log refs
freshness/invalidation state
```

### VerificationAuthority

System authority that decides which evidence is required, admissible, current and sufficient for a lifecycle gate.

## Invariants From Day 1

- agent statement “tests pass” is not authoritative evidence without admitted receipt;
- evidence binds to exact relevant input identities;
- reuse is preferred while evidence remains valid;
- candidate/config/dependency/environment changes invalidate only affected evidence where determinable;
- smallest meaningful falsification check is preferred;
- broad testing requires a concrete risk/blast-radius/gate reason;
- no fake green: expected/not-started/skipped/failed remain distinguishable;
- retries preserve failure history and may indicate flakiness;
- gate disposition and reasons are persisted/auditable.

## Quality Rule

```text
Use the smallest check that can meaningfully falsify the implementation.
Broaden only when risk, blast radius, evidence failure or a required gate justifies it.
Stop when sufficient evidence exists.
```

User journeys/CUJs drive E2E selection. Smoke checks prove narrow operability. Coverage is multidimensional; no universal percentage is assumed.

## I1 Thin Seam

Before full authority activation, MergeGate still consumes authoritative check receipts from focused verification and repository-required GitHub checks plus Review/fidelity state. Evidence records use final IDs/inputs so I5 can deepen without migration to a new concept.

## Gate Model

Gate evaluation returns:

```text
passed
blocked: missing evidence
blocked: failed evidence
blocked: stale/invalidated evidence
blocked: policy/approval
blocked: unresolved review
```

It also returns exactly what is required next.

## Evidence Invalidation

Invalidation keys may include candidate digest, affected files/capabilities, build/runtime dependency lockfiles, check definition, environment fixture, schema/config revisions or explicit policy change.

## Increment Realization

| Increment | Verification realization |
|---|---|
| I1 | thin evidence receipt + trusted MergeGate inputs. |
| I2 | Planning creates QualityStrategy/CIPlan expectations. |
| I5 | full Authority/planning/admission/ledger/invalidation/gates. |
| I6 | release/deployment gates and artifact evidence. |
| I8 | resolver fixes require verified evidence before reusable recipe/normal merge. |

## Current Implementation State

Target spec; full VerificationAuthority is intentionally not implemented in I1.

## Deferred Realization

Advanced statistical flake analysis/optimization is I5+ and may use FOSS/provider data; it cannot weaken gate correctness.

## Temporary Dogfood Behavior

I1 can map one check result directly into VerificationEvidence. It must record exact provenance rather than invent a generic boolean `verified=true`.

## Failure / Recovery

Unavailable check infrastructure yields infrastructure/error evidence, not failed product behavior. Stale evidence triggers focused re-verification rather than blind full suite.

## UI Implications

Every gate explains what evidence was expected, executed, reused, invalidated, failed or omitted and why. Users can drill into receipts/logs without parsing raw CI JSON.

## Decisions / ADRs

Canonical detailed rationale remains in `AWP-VERIFICATION-ENFORCEMENT-DESIGN.md`; this spec is target implementation authority.