Consider what the check does with an absent input. It reads `serves_line`, gets `None`, has nothing to compare `must_not_have` against, and returns no finding [9]. Static analysis sees a rule with real callers, invoked on every contract [4], and coverage tooling sees the line execute. The record shows no violations and no exemptions recorded, which is exactly what clean looks like from outside [18].
That places this one layer below three failure modes the same author has already written up: rules nobody called, a correctly-called rule whose target population was empty at runtime, and a rule that disabled itself because its threshold was an absolute constant that did not match the input's scale [5]. Here the wiring was present at the call site and missing at the producer [4].
So the query to run is not "who calls this rule" but "what fraction of invocations had a non-null value in each field this rule reads." Over the published episode described in the post, that is five shots and five nulls, a fill rate of 0 percent [10][22]. Repo-wide, the count of code paths that write the field is zero, because the archetype templates that generate contracts never set it [8].
The backfill is the part worth copying. The derivation was checked against reality first, and 6 of 6 stored values matched their beat's narration with no drift [7]. Wiring it turned the rule live and the tests stayed green [11], which by this point in the sequence tells you very little. Replayed over every contract it could now evaluate, the rule fired eight times and caught no real contradiction [12]. Measured precision: 0 of 8 [20].
The reason sits in the operand types. `serves_line` is narration, which is audio; `must_not_have` governs pixels, which is what appears on screen [13]. The rule was matching a spoken quantity against a visual numeral ban and calling the co-occurrence a conflict [14]. The best-authored contract in the repository has a `must_have` that reads "blank faces free of pips and numerals," blank dice while the voiceover speaks the numbers, and its author had declared that relationship metaphorical specifically so the tooling would leave it alone [15]. It was flagged anyway [15].
Treat 0 of 8 as a claim about one repository and one video pipeline, at n=8. For that number to say anything about your suite, two things would have to hold: the dormant rule's input would have to be a derived field produced by templates rather than by an explicit writer, and its two operands would have to sit on channels that can legitimately disagree without either being wrong. What transfers without those conditions is the order of operations. Ask who writes each field a rule reads, not only who calls the rule [19], and verify the positive class retroactively before you supply the input that makes the rule live.
In my context I would take the same trade. A dormant rule carrying its measurement in a comment costs one comment [17]. A live rule with an unverified positive class hard-fails authors at author time [2], in the window where they are trying to publish. The structural fix here is the reporter that names the unmeasured state, so a spotless history stops being read as a verdict [18].
