Case study: UNKNOWN is not clean

Candidate redacted meta example — not yet Task Library accepted · Operations Web Function 0.1.0.

Download the complete plugin · Source SHA-256: a6ffe405e9d953809e5c60e453d243734f5ebbac7b183e6582e55708738ac0d8

An access audit once allowed failed probes to disappear into a gap-free result. Later inspection showed that many of those properties were reachable and had real measurement gaps. The absence of evidence had been rendered as success.

The corrected audit distinguishes verified coverage, verified gaps, bot or policy blocks, transient failure, genuine unreachability, and COVERAGE_UNKNOWN. It serially rechecks suspicious results and asserts that all state buckets add back to the declared denominator.

A dated August 10 run covered 285 properties and left 21 explicit unknowns. That is more honest and more actionable than a smaller green number.

What changed in the reusable SOP:

UNKNOWN is a data state, never a score of zero or a pass;
a blocked observation path says nothing conclusive about target health;
every partition includes a residual bucket and assertion;
reports state what the operator must do to resolve each unknown;
client-facing language describes our evidence gap, not a deficiency in the client.

Property rows, account identifiers, credential coverage, and client identities remain private. Evidence tier: E3.

This page is generated from examples/case-studies/03-unknown-not-clean.md. Do not hand-edit the public copy.