Adding a 'could not tell' result to checks exposed four new ways to misread them

With only two outputs, the probe had no way to report that it could not read a file. The empty ruling was filed as "no" ^[5]. That ruling was one of two conditions, and either one was enough to lift the hold ^[4]. When the author, writing on dev.to, flipped the other condition to "met" as an injected fault, the probe returned 0, "may be lifted", on a hold nobody had cleared ^[6]. The empty read surfaced only because of that deliberate fault ^[6].

The fix is good work. The probe now reads every matching file and records where the value came from ^[7]. If either condition cannot be read, it refuses: 0 means may be lifted, 1 means not yet, 4 means one condition could not be read ^[7]. The part I would copy is the test set, four controls with one per outcome, including a missing-condition case that must return 4 ^[8]. The author reports it has held since ^[8].

The same week showed four new ways to be wrong, according to the post, which covers mistakes made between 15 and 24 September 2026 ^[3]. One is a result that looks like a measurement. On 24 September the author ran grep -c 'bash","-c' tool.py to see whether a line passing stored text straight to a shell was still present, and got 0 ^[9]. The source had a space after the comma, "bash", "-c", so the pattern could not match ^[10]. A single space separated a closed risk from an open one ^[19]. grep did exactly what it was asked. The command succeeded and printed a clean number. This matches the third case a reader proposed for agent evals: ran, but could not establish the claim ^[2].

A wider search for subprocess, bash and -c found the line at 147 ^[11]. The rule the author wrote afterwards: "a zero from a pattern I have never seen match is unknown, not absent." ^[12]

Another is the friendly name. NOT_APPLICABLE is honest when a leak scanner runs on prose that contains no key assignments ^[13]. The gate that checks the author's articles returns it on them ^[14]. Its owner showed the gate returns the same value when a file holds an assignment it fails to recognise. A key name with a common prefix and underscores had slipped past its word boundaries ^[14]. "Nobody audits a not applicable," the author wrote ^[15]. Now, faced with not applicable, the author asks what the tool would have done with a known example, and records unknown if there is no answer ^[16].

A third is one word covering several facts. A weekday check on three helper processes reported "alive" ^[17]. Split apart, alive meant the supervisor is running, the worker has produced output recently, and no requests are waiting unanswered ^[17]. The supervisor can run for days around a worker that has done nothing ^[18]. On three separate days the "most recent activity" signal came from something other than the worker, once from a database side-file ^[18].

The grep zero and the gate's not applicable share one fault. Neither tool had been shown to catch the thing it was looking for ^[11][14]. For agent evals, I think the reader's split into not run, ran and passed, and ran but could not establish is the right schema ^[2]. I'd add one rule to it. A harness result leaves the "could not establish" bucket only after that harness has a recorded run in which it caught a known positive.