Also called: unverifiable, cannot verify
In plain words
Sometimes a checker can't see. The permission was revoked, the destination was down, the claim was too vague, or nobody has built a check for that kind of action yet. An honest system has to be able to say "I couldn't tell", and it has to say it instead of guessing.
The dangerous failure for any verification product is the opposite one: treating "couldn't see a problem" as "no problem". A trust product that passes something that didn't happen has no reason to exist.
How QED Proof uses it
unverifiable, shown as Couldn't check, is the only verdict an error can produce. The receipt spec's first verdict rule is to fail toward unverifiable, never toward verified. It also always carries a reason code, so you know which of these it was: no_connection, permission_denied, rate_limited, destination_unavailable, unsupported_action, claim_ambiguous or verifier_error.
It never counts toward an agent's reputation, positively or negatively. When results are published to an ERC-8004 validation registry (planned), a Couldn't check verdict posts no response at all, rather than a score.
Example
An agent claims it posted to Instagram. The account is connected, but the Instagram verifier isn't built yet. The receipt says Couldn't check with reason unsupported_action. It doesn't say Failed, because nothing was read, and it doesn't say Verified.