What is outcome verification?

Outcome verification is one operation with one shape:

A claimed result goes in. External evidence determines whether it is true.

It is worth being precise about each half of that sentence, because both halves are doing work.

A claimed result, not a task

The input is a statement about the world that should be true after some work was done. Not a list of steps, not a test case, not a description of the implementation.

• A claim: a customer who pays for Pro gets Pro access, and still has it after signing in again.
• Not a claim: click the upgrade button, then fill the card form, then check the account page.

The difference matters because steps encode an assumption about how the outcome is achieved, and that assumption comes from the same place the bug did. A claim is about the result, so it survives the implementation being wrong.

External evidence, not self-report

The evidence has to come from outside the system under test, gathered by exercising the real deployment rather than reading its source or asking it how it went.

This rules out most of what is currently called testing. A unit test is written by the same author, from the same understanding, and passes when the code does what the author expected. That is valuable and it is not independent. A verification that consults the implementation to decide what to check has already lost the property that makes it worth running.

What it is not

• Not monitoring. Monitoring tells you something broke after customers found it. Verification runs before you rely on the result.
• Not a test suite. A suite checks the cases someone enumerated. A verification checks whether a stated outcome is true.
• Not a code review. Review reasons about the implementation. Verification ignores it and looks at the result.
• Not a status page. Availability is not correctness. A checkout that returns 200 and grants nothing is up.

Why it needs to be a separate thing

You could argue this is just testing done well, and in a sense it is. The reason it needs its own name and its own system is the independence requirement. The moment verification lives inside the thing being verified, written by the same author or the same model, it inherits that author's blind spots and stops being evidence.

Independence is not a quality bar you can reach by trying harder. It is a structural property, and structure is the only way to get it.

The output

A verification returns a decision and the evidence behind it. Three answers, and the third one matters more than it looks:

• Verified. The claim held, with evidence.
• Failed. The claim did not hold, with evidence of what happened instead.
• Blocked. No verdict was reached.

Collapsing blocked into either of the others is the most tempting mistake available. Reporting it as verified is a false pass, which is the worst possible failure for a system whose entire value is being trustworthy. Reporting it as failed is a false alarm, which trains people to ignore it. A verification that cannot reach a verdict has to say so.