What does “not verifiable” mean in a report?

OK — the thing was observed and it is correct.

WARNING — observed, and partially wrong or worth attention rather than broken.

FAIL — observed as missing or broken. This is reserved for something really seen, never for something that could not be looked at.

INFO — observed and reported as information, with no judgement attached. A detected technology is information, not a verdict.

NOT_VERIFIABLE — the check ran and could not establish an answer from outside.

A report that silently turns unknowns into passes is flattering and useless: it tells you a site is fine in areas nobody examined.

A report that turns them into failures produces a list of things to fix that are not necessarily broken, which teaches people to ignore the list.

Keeping the third state means a clean report means something: the things that could be checked were checked, and the ones that could not are named.

It is also what makes the coverage figure meaningful, since unverifiable results are counted separately from verified ones.

Which is the difference between a score you can act on and a number.

Verified directly — observed in a response that was really made. A header read from a real response is this.

Detected or inferred — derived from observable signals rather than stated outright. A platform identified from a fingerprint is this.

Not publicly verifiable — the answer cannot be established from public information at all.

A result can be OK with low confidence, which means the evidence points one way and does not prove it.

The score weights results by confidence rather than treating an inference as a measurement, which is why an inferred finding moves it less than a directly observed one.

Backups and disaster recovery, which leave no observable trace on the public internet.

Whether multi-factor authentication is enforced, as opposed to publicly mentioned — enforcement is only visible from inside an account.

Whether a mail server really negotiates encryption, which requires an SMTP connection rather than a DNS query.

Whether a health endpoint's healthy answer is accurate.

Whether the allow-list behind a correctly echoed cross-origin header is actually sound.

Read it as a question rather than as a finding: somebody inside can answer it in a minute.

Use it as a checklist for the parts of an audit that external tooling structurally cannot do.

Do not chase it in the report. Nothing you change on the site will turn it into a pass, because the limit is the vantage point rather than the configuration.

Where the answer matters — backups, recovery, enforcement — record it somewhere that is not a scan result.

And treat a tool that never reports this state as a tool that is guessing somewhere.