Verification Requires Independence

The Distinction

Verification is a claim made by a party that is not the system under review, using evidence that does not depend on that system's honesty or availability. It requires a separation: the thing being checked and the entity doing the checking cannot be the same.

A system that checks its own output has performed a check. It has not performed verification. "Self-verification" is a contradiction — the prefix collapses the property the word is supposed to guarantee.

Independence is not a quality property of verification, the way "thorough" or "rigorous" might be. It is the minimum threshold. Below it, what you have is introspection wearing a different label.

This is not a semantic complaint. When a system reports on its own correctness, the accuracy of that report is bounded entirely by the trustworthiness of the system. A compromised system produces favorable self-reports. A misconfigured system produces accurate reports of its own misconfiguration — which it cannot detect. The reports are not false in the ordinary sense. They are simply not evidence.

Why It Matters

The failure mode is adoption of false certainty at governance boundaries. A team runs a verification step and believes the system has been independently checked. The verification step queries the system itself. The belief is wrong, but no one knows that — least of all the governance record, which shows the check as passed.

This matters most when someone acts on the verification result. A downstream operator grants elevated access based on a passed verification. A compliance attestation cites the result as independent evidence. A contract clause ties liability to whether verification passed. Each of these actions inherits the assumption of independence. None of them inherit the actual independence, because it was never there.

The failure is structural, not adversarial. It does not require bad actors. A well-intentioned team that wires verification to self-reporting has built a system that cannot distinguish correct operation from failure modes that affect the reporting path.

Real-World Example

An AI agent platform runs an internal policy compliance check before each deployment. The check executes inside the same runtime as the agent, reads policy configuration from a store the agent has write access to, and logs the result to an internal ledger. The deployment pipeline gates on a passing result.

A misconfiguration in the policy store causes an overly permissive rule to be loaded at runtime. The compliance check runs, reads the permissive rule, finds no violations, and logs a pass. The deployment proceeds. The agent is deployed with permissions that should have been blocked.

No one falsified a log. The check ran. The gate passed. The evidence chain is intact. The problem is that the check was interrogating the same configuration surface the misconfiguration affected. The verifier and the verified were the same system.

The Test

Before treating a passed verification as evidence of correctness, ask:

Could this verification have passed if the system under review were producing incorrect output and had control over the verification inputs?

A passing answer requires a clear separation: the verifier reads from a source the system cannot write to, and the verification result is signed or anchored by a party outside the system boundary.

A failing answer looks like: "the check queries the system's own state" — regardless of how many layers of tooling are in between.

Closing Principle

A system that verifies itself has performed a check. Whether that check is useful depends entirely on whether the check and the system share a failure domain. If they do, the check tells you nothing about failures that affect them both — which are exactly the failures you most need to detect.

Independence is not a design enhancement. It is the property that makes the word "verification" apply at all.

See also: Independence Without Replay Is Still Weak — the follow-on distinction: what independence proves, what replay proves, and why a proof surface needs both.