An output is not an artifact.

A convincing explanation can describe software that does not exist. Verification has to meet the thing we actually built.

Start with acceptance

State what the system must do before asking an agent to implement it. Name the inputs, expected behavior, constraints, and failure cases. A requirement that cannot be checked leaves too much room for a plausible answer.

Inspect the artifact

A passing unit test is one piece of evidence. Open the application. Exercise the workflow. Inspect the output file. Check that the deployment contains the change. The level of inspection should match the consequence of being wrong.

For generated interfaces, that includes the browser. A valid component tree cannot tell us whether the heading wraps badly, the focus disappears, or the main action sits outside the viewport.

Make failure useful

Keep the failing input and the observation that exposed the problem. Repair the system, then run the same check again. When appropriate, turn the example into a regression test that protects a meaningful behavior.

Keep review independent

The implementation’s own account of success is not enough. Review should use the acceptance criteria and observable behavior. A reviewer should be able to disagree, reproduce the failure, and explain what evidence would change the conclusion.

This is an engineering method, not a claim that every failure can be predicted. The goal is to make success inspectable and failure easier to find.