A review question that never produces a finding is indistinguishable from one guarding a clean tree, and the ceiling makes it displace rather than sit there

[HackingGate]

ROADMAP.md already records the static half of this as a known non-goal, with
its reason: detecting that an installed rule never fires needs firing counts from
the tiers themselves, and needs "clean tree" separated from "dead rule" before
the signal is worth anything. That entry is not being re-filed.

This is the other half, which is recorded nowhere: the same defect in the
review tier, where it is both harder to see and cheaper to introduce.

Why the review tier is worse off than the static one

A static rule that has been switched off leaves a trace. It is absent from a
config file, and uphold check reconciles claims against configuration and
refuses a claim whose rule is no longer there. The failure is loud by
construction, and that loudness is the point of policy/upheld.toml existing at
all.

A review_questions entry that no review has ever acted on leaves no trace of
any kind:

• it is textually present, so nothing looks missing
• it passes --check, because the compiled document is generated from the
  record and is therefore never stale -- staleness is the only failure mode the
  emit gate can see, and this is not one
• it is indistinguishable from a question guarding a clean tree, which is the
  same ambiguity the roadmap names, arriving here without even a config file to
  inspect

There is no reconcile for the review tier because there is nothing on the other
side of it to reconcile against. upheld.toml names a rule; nothing names a
question that worked.

And here it displaces, rather than merely sitting there

The static case is inert: a dead rule costs a line in a config file. The review
case is not, because [review] max_lines is a hard ceiling that fails the build.

Dead weight in a length-capped document is not neutral. It consumes budget the
ceiling then denies to something a reviewer would have used. The ceiling was set
to stop the tier degrading into guidance long enough to be skimmed, and it does
that job honestly -- but it cannot tell which 900 lines were worth keeping, and
right now neither can anyone else.

What is decidable, and what is not

Not proposing model telemetry, and not proposing a ranking heuristic --
scripts/review.py already refuses the latter for length, on the ground that a
reader cannot tell a short document from a truncated one, and the same objection
applies to a scoreboard that quietly drops the tail.

Something narrower is observable: the record a finding cites. The compiled
document is already organised by record, each block headed by the id, so a
reviewer filing a finding can name the record it came from at no extra cost --
and a record with zero citations across N reviews is a candidate for having said
nothing anyone could use.

The limit, stated rather than papered over, is the roadmap's own: zero citations
is not zero applicability. A record can be silent because nothing violated it.
Separating the two needs a denominator -- how many reviewed changes did this
record's applies_when actually describe -- and that is a second measurement,
not a free one. Until it exists the count is a hint, and must be reported as a
hint.

Why this is worth an issue now, and not later

#64 proposes emitting one unit per record instead of one document. That converts
this from a hint into a requirement.

A record inside the compiled document has, at minimum, the property that it was
read: everything under the ceiling reached the reviewer. A conditionally-loaded
unit does not have that property. It can fail to be selected, which is a
failure one step earlier than failing to fire, and it leaves even less
evidence -- no citation, and no record that it was ever considered and rejected.

So #64 should not land before there is some answer here, or the tier acquires a
silent failure mode in exchange for removing a loud one.

[HackingGate]

Citation counting answers "did any reviewer use this record". There is a second
question underneath it that the same data cannot answer: "could this record
produce a finding at all". Those are the two halves of the ambiguity this issue
names, and only the first needs a denominator.

The second one already has a mechanism in this repository. uphold probe exists
because a hook that has only ever been seen passing is indistinguishable from one
that cannot fail, and it settles that by planting what the hook is supposed to
catch. The review tier has the same defect and can borrow the same shape:

[[review.control]]
record = "single-authoritative-source"
catches = "a bespoke page summarising what an existing renderer already writes"
misses  = "a change to that renderer"

A reviewer is run against the control and must name the record. A control the
reviewer does not catch means the record cannot fire, which is a different
verdict from zero citations and is available without waiting for N reviews to
accumulate.

The precedent carries across in its details as well. probe refuses an empty
refuses fixture, because an empty fixture demonstrates nothing and a hook that
accepted it would be reported as unable to fail; the same refusal applies to an
empty catches. probe prints the count of declared hooks with no probe
every run, so "two hooks were probed" reads differently beside two declarations
than beside twenty; the review tier needs that count more, not less, because a
record with no control is exactly the record this issue is about.

What it does to the denominator problem

Not solve it. A control is a synthetic change that the record's applies_when
describes by construction, so it measures capability and not applicability. What
it does is remove "dead" from the candidate set: a record whose control is caught
is silent because nothing violated it, and a record whose control is missed is
silent because it says nothing usable. Citation count then measures use rather
than existence, which is the weaker claim it can actually support.

Measured, on one workspace

I ran this over a hand-written rubric of eight review-carried classes, with
planted defects and a key. The first run named eight for eight, and two more the
key did not hold. Both were real, and they are planted deliberately now. Two
things follow. The mechanism discriminates rather than rubber-stamping. And the
key grows by discovery -- an entry nobody found first is a defect written by the
same reader who scores it, which is the scoreboard failure mode this issue
already refuses for length.

The honest exposure: a control is written by whoever wrote the record, so it can
be written easy. probe has the same exposure and answers it by keeping the
fixture in a file where it is reviewable, which is the answer here too.

On #64

A control is also the only thing in this design that observes a selection
failure. A conditionally-loaded unit that is never selected produces no finding
and no citation, and neither absence is distinguishable from a quiet tree. It
does fail to catch its own control, and that is observable at the moment it
happens rather than after N reviews. If #64 needs an answer here before landing,
this is the half that reaches the failure #64 introduces; citation counting
reaches the one that already exists.

[HackingGate]

Related from the other side: #71 proposes a rule disposition = "review" -- a review question with a matcher, emitted by the scanner rather than compiled into the document.

It does not close this, but it bears on both halves recorded here. A triggered question has a hit count, so "dead" and "guarding a clean tree" become separable for that class -- which is the ambiguity this issue says has nothing on the other side to reconcile against. And it costs no lines from [review] max_lines, because it is not in the compiled document at all, so it removes one class of entry from the tier the ceiling squeezes.

Filed as a question rather than a proposal; the objection it has to survive is docs/DESIGN.md's standing asymmetry, which argues that anything mechanizable should be pushed into the static tier instead.