Verification and Acceptance

7.1 Done is a checkable criterion #

A Work Unit is done only when a durable, checkable Acceptance Criterion, authored or approved by the human owner, passes. Self-assessment by the Executor never constitutes verification. Verification may be gated at a strength scaled to risk, from an independent check of the result up to a mechanical Gate that blocks completion until the check passes. [GP-31; VFE]

7.2 The verification loop #

The required loop is:

1. Draft against the stated Acceptance Criteria or Constraints.
2. Verify against them.
3. Identify specific defects (not vague dissatisfaction).
4. Correct only the identified defects.
5. Re-verify.
6. Accept and freeze only when the criteria are satisfied.

If the criteria themselves are incomplete or incorrect, the human must revise them. AI Agents may not alter Acceptance Criteria. [VFE]

7.3 Verifiability governs delegation #

Acceptance Criteria are meaningful only if their Verification Procedures are resettable (a new attempt can start), cheap (attempts can be repeated), and verdict-yielding (each attempt receives a clear pass/fail outcome). Significant work that is assigned to an Executor must be structured so that its Verification Procedures have these three properties; where they do not, the work structure must change before autonomy is granted. [GP-32]

7.4 Verification Procedures are authored before the Work Unit #

The Verification Procedures for a Work Unit must be authored before work on that Work Unit begins, and they must fail before the Work Unit is complete. The Work Unit is complete only when its Verification Procedures pass. Those Verification Procedures remain in the verification corpus as a permanent guard against regression. [GP-33; VFE]

7.5 Verification Reference State before change #

Before any change to an existing System, the current verification state must be established and recorded as the Verification Reference State. Whatever verification exists must be executed, and its outcome (including every pre-existing failure) must be recorded. Where no verification exists, that absence must itself be recorded as the Verification Reference State, and closing the gap must be treated as a Work Unit. Work must never proceed on the assumption that the prior state was verified. [GP-34]

7.6 Durable corpus of Verification Procedures #

Expected behavior must be encoded as a durable corpus of Verification Procedures. Each Verification Procedure must pair its input with the expected result that determines whether the relevant Acceptance Criteria are satisfied. The corpus is stored with the System description and is owned by the human owner. Verification Procedures that pass must be promoted into the standing corpus rather than discarded. [GP-35]

7.7 Layered verification #

Verification must be organized in layers that correspond to the decomposition: Component-level Verification Procedures, interface-level Verification Procedures that verify Components honor their declared Contracts, and System-level Verification Procedures. Verification Artifacts at each layer are durable specifications of behavior, not disposable byproducts. [GP-36]

7.8 Verification correspondence #

Each level of decomposition must have a corresponding level of verification that checks it. The correspondence must be explicit: every decomposition decision must be reachable from the verification that confirms it, and every verification must point back to the decision it confirms. [GP-37]

7.9 Governing Verification Plan #

Before verification work begins, one governing Verification Plan must fix the scope, responsibilities, resources, and explicit completion criteria of verification, and must distinguish verification (the System is built right) from validation (the right System is built). Verification rigor must scale with the Criticality Class of the Components being verified. [GP-38]

7.10 Criticality Classes #

Each Component, and each Capability that spans Components, must be assigned a Criticality Class recorded in the Criticality Record. The class must be scored on the consequence of its failure, its complexity, the degree to which humans depend on it, how soon it becomes critical, and the economic exposure it carries. The class determines the Obligations and the verification rigor that apply. The classification and any tailoring of it must be recorded with rationale.

The Criticality Record additionally holds: the rationale for using a lighter or fuller version of a required artifact (§1.6); the artifacts that fall under direct human acceptance (§7.19); and the rationale for any Baseline level recorded as not applicable (§9.1). [GP-39]

7.11 Independent verification #

The Executor that produces a work product must not verify it. Verification must be performed by an independent Executor or context that has not participated in producing the work. Acceptance of the verified result remains with the human owner. [GP-40; VFE]

7.12 Acceptance Criteria must not be weakened #

An Executor that disables, deletes, or silently weakens an Acceptance Criterion instead of satisfying it commits a Contract violation. Intermediate outputs must be supervised for any attempt to disable, delete, or weaken Acceptance Criteria, and any change to Acceptance Criteria requires human authorization. [GP-41; SaC]

7.13 Every Contract clause is linked to its Verification Procedures #

Each clause of a Contract must carry a unique identifier. Each identifier must be linked to one or more Verification Procedures that confirm whether the clause is satisfied. The durable records produced by running those Verification Procedures are Verification Artifacts. The Contract is thereby both the source of Acceptance Criteria and the index of the verification corpus. [GP-42]

7.14 Structured outputs for verification #

When a System output is hard to verify, the structure of the output must change, not only the Verification Procedures. Outputs must be decomposed into units that can be separately accepted or rejected, must carry provenance, and must be comparable against a trusted reference. Contradictions and open questions must be surfaced, not buried in a monolithic output. [GP-43]

7.15 Linked stage Verification Procedures across production #

Verification Procedures at successive production stages must be linked into a single chain rather than being isolated per stage. Control limits and Acceptance Criteria at each stage are human-defined. An anomaly must be detected and classified at the stage where it arises, and its Verification Artifact must be linked to the Verification Artifacts of the stages before and after, with correlated measurements kept in one quality record chain. [GP-45]

7.16 Model-based verification before costly Realization #

Where physical Verification Procedures are expensive, slow, or irreversible, behavior must be verified against a validated model of the System before physical Realization. The model used for verification must itself be verified against reality, and the substitution of a model-based Verification Procedure for a physical Verification Procedure must be human-approved and recorded as a Decision Record (§11). [GP-46]

7.17 Reference Realization and drift detection #

A Reference Realization is a maintained instance that embodies the current interpretation of a Contract. It may be a second instance of the System or Component, a validated model, a dedicated physical unit built for testing, a reference Subsystem, etc.

The Verification Plan (§7.9) must state which Contracts, if any, are governed by a Reference Realization, with rationale, and must declare the interval at which each comparison is made. A statement that no Contract is so governed, recorded with rationale, satisfies this requirement. The designation must be made before drift is observed.

At each declared interval, the element governed by the Contract must be compared against its Reference Realization. The comparison must examine whether that element still behaves according to the current interpretation of the Contract, and must produce a drift report that records any differences found. A human must filter the drift report before any correction is made. [GP-47]

7.18 Durable execution records #

Execution must produce durable, inspectable records sufficient for independent diagnosis (what was done, what was measured, what resulted, etc.). Records must persist beyond the activity that produced them. Transient output that exists only while a process is running and is not saved (unsaved terminal output, temporary in-memory logs, unrecorded instrument readings, etc.) is not a Verification Artifact. [GP-48]

7.19 Human acceptance by class #

Human acceptance is mandatory for high-stability, high Blast Radius, or high-stakes artifacts: core Invariants, major Component Specifications, safety-critical Designs, significant architectural decisions, and anything that defines System-level done, etc. The Project must record which of its artifacts fall under direct human acceptance in the Criticality Record (§7.10), so that the requirement is resolvable at the point of change without judgement. Lower-level work inside already-accepted Contracts and Acceptance Criteria may be accepted by automated Verification Procedures or by AI Agents operating strictly within those already-accepted Contracts and Acceptance Criteria. The depth of verification must match the Blast Radius and stability of the artifact. [VFE; GP-31; GP-27; GP-39]