Verification Evidence

A claim that something works, is fixed, or is broken is worth what stands behind it. This skill defines what can stand behind a claim. The calling step decides which claims need it, how strong the evidence must be, and how its report presents the result.

Name the Kind of Evidence

Evidence comes in kinds, strongest first:

1. Observed — the behavior itself, seen where it actually happens: the running system, the real endpoint, the deployed service.
2. Executed — a test or command that exercises the behavior in a controlled environment.
3. Traced — the code path followed step by step from input to result, without running it.

Anything else — a clean build, a plausible diff, an agent's summary, "it should work" — is not evidence for the claim; at most it points to where to look.

State which kind backs each claim. A claim whose evidence is weaker than the step requires — or that has none — is reported as falling short, using the calling step's label for that, never as settled. Never report a weaker kind as the stronger one.

The Check Must Be Able to Fail

A check supports a claim only if it would have failed were the claim false. Decide what result counts as passing before running the check, not after seeing the result. Where the calling step leaves the choice of check open, prefer the one most likely to fail if the claim is wrong over the one most likely to pass. Ask of every check: