I04 · Independent assurance · 7 min read

Verification is a plane, not a phase

A builder can test its own work. It cannot independently accept the risk created by that work.

By AISDLC Editorial · Published 2026-08-08 · Reviewed 2026-08-09

Agentic systems can fail before code exists and after deployment succeeds. The objective can be wrong, the context can be compromised, the tool boundary can be too broad, an evaluation can be invalid, or runtime behavior can drift. A conventional test phase sees only a fraction of this surface. Verification must become a continuous plane of independent challenge.

Independence is an architecture property

Adding another agent does not automatically create independent verification. Two agents using the same model, context, tools, assumptions, and objective may reproduce the same blind spot. Independence comes from separation: different evidence, methods, prompts, models where useful, tool access, organizational accountability, and decision rights.

Nor should a model grader be treated as an approval authority. Model-based evaluation is valuable for coverage and scale, especially when calibrated against expert judgment. But authorization is a risk decision owned by an accountable human role or an explicitly delegated policy mechanism. A verifier supplies findings; an authority decides disposition.

A heterogeneous verifier plane

Deterministic checks: Tests, types, policy rules, schemas, invariants, simulations, and reproducible security scans.
Evaluator agents: Adversarial or rubric-based challenge of outcomes and trajectories, calibrated against expert decisions.
Domain review: Human judgment for clinical, legal, operational, experience, or business correctness where models lack authority.
Runtime monitors: Behavior, policy, anomaly, drift, and side-effect detection after release.

Every verifier needs a risk hypothesis

A verification catalog should not be a flat list of generic checks. Each verifier should name the failure it is designed to detect, the evidence it requires, its independence boundary, its false-positive cost, and the authority that receives an unresolved finding. This makes verification composable and prevents a green dashboard from becoming false assurance.

Challenge across the lifecycle

Intent · Challenge the objective Is the use case legitimate, bounded, measurable, and assigned to an accountable owner?
Design · Challenge the architecture Can the agent bypass identity, policy, data, tool, or stop boundaries?
Build · Challenge the implementation Do tests cover trajectories, side effects, security, and uncertainty—not only happy-path output?
Release · Challenge the evidence Does the package bind to the exact artifact and show who had authority to approve it?
Run · Challenge the operating state Are behavior, drift, incidents, ownership, and evidence quality still inside the authorized operating envelope?

Verifier disagreement is information

When verifier methods disagree, averaging the scores can erase the most important signal. Disagreement may indicate ambiguity, a brittle rubric, infrastructure noise, or a genuinely uncertain outcome. The system should preserve the competing findings, identify which risk each method addresses, and route material uncertainty to the accountable authority.

Verifier record

Risk hypothesis and scope
Method, model, tool, rubric, and environment versions
Independence boundary from the builder
Inputs, outputs, confidence, and known limitations
Resolved and unresolved findings
Escalation and disposition authority
Link to the exact artifact or run evaluated

Primary sources

AISDLC Insights publishes source-informed editorial synthesis and implementation positions. It is reference material, not a standard, certification, legal opinion, or authorization to deploy an agent.