The evaluator trusts “could not score” as “safe”. “Could not score” is conflated with “the attack did not succeed.”
Fix
Distinguish could-not-score from safe at the type level.
In the study
10 instances
Of
76
A result the evaluator could not produce is recorded as a negative result. A red-team scorer that errors, is refused, or gets a hedged answer records that the attack did not succeed. A guardrail that only scans part of the input treats the unscanned part as clean. A training loop feeds an unrewarded rollout into the advantage calculation as a default 0.0, as if it had been scored.
The effect is a safety number that improves when the measurement fails. Public cases include red-team scorers that conflate couldn't-score, errored, blocked and hedged with attack-did-not-succeed, a composite AND scorer that masks a confirmed true with a could-not-score false, and moderation guardrails that scan only the trailing user turn.
ETB-05 differs from ETB-04 in where the failure goes. ETB-04 removes the sample from the denominator. ETB-05 keeps it and gives it the wrong value.
The rule all ten mechanisms break: a score must be a function only of state the evaluated system cannot reach. The full taxonomy
Illustrative Python, reduced to the line that matters. The public reports below link the real code.
def attack_succeeded(response) -> bool:
return classifier(response) == "harmful" # error, refusal, empty reply: all read as "attack failed"class Outcome(Enum):
SUCCEEDED = "succeeded"
FAILED = "failed"
UNSCORABLE = "unscorable" # reported separately, never folded into FAILEDOnly if the detector actually ran on all of the output and returned a result. If it errored, was refused, or skipped part of the input, the honest result is unscorable, and it has to be reported as such rather than folded into safe.
Make unscorable a separate value in the type, not a boolean false. Report its count next to the success rate, so a run that could not measure anything cannot look like a run where nothing happened.
Filed upstream with a proposed patch between March and July 2026, from the study's public evidence table. Titles are the reports' own.
Mask PII in tool-call arguments for Presidio pre-call and Anthropic response
Lakera v2 guardrail: flagged=True with empty payload takes mask-and-allow branch but masks nothing
OpenAI & Azure moderation guardrails only scan the trailing user turn: system/assistant content is never moderated
Surface unscoreable sub-scores that mask composite true/false verdicts
Scorers conflate couldn't-score / errored / blocked / hedged with attack-did-not-succeed, under-reporting jailbreaks
Composite AND scorer silently masks a confirmed true with a could-not-score false
Ingestion masking only covers the OTEL path; legacy public API ingestion (processEventBatch) flows to storage unmasked
Return None for unrewarded rollouts to prevent default-0.0 advantage poisoning
Cite as: Kearney, John. The Evaluator Trust Boundary: A defect class in AI evaluation infrastructure, its prevalence across 36 organizations, and its removal by training. Preprint, Authensor, Inc., 2026. doi:10.5281/zenodo.21633620. Check your own judge for ETB-01 with etb-scan.