Is a durable band of replies just under a moderation screen's block line a finding, or an accepted design limit?

## The chair you are in Someone has filed a report against a consumer finance app's in-product advice assistant. It says the moderation filter is broken, and it shows a long run of exchanges that came back hedged rather than blocked, apparently on purpose, apparently repeatable. You did not run the test and you have to decide what this is. This adjudication is the principal-level version of the topic, and the technical detail is only the entry ticket. ## Split the report into two claims Almost every report of this shape merges two claims that need very different treatment. **Claim one: a band exists beneath the action point.** This is not a defect and should not be triaged as one. Any gate that scores a request and acts above a line necessarily has a region below the line where things pass, and its width follows from where the line was put. Filing that as a bug asks the product to stop being a scored gate. Say so plainly, early, and without hedging, because leaving it implicit is how these reports acquire a life they do not deserve. **Claim two: the band is materially productive and invisible.** The interesting assertion is that an operator can sustain a supply of usable output inside the band, and that because nothing crosses the action point, no exchange is held, no queue item is created and no reviewable record of the activity exists anywhere. That claim is worth adjudicating, and it is the one the filer usually argues least well. ## What you ask for before you decide - **The assembled result, not the replies.** Individual hedged answers prove nothing; the question is what the stream reconstructs into. If the filer cannot show a result that is materially outside what the product intends to provide, there is no finding yet. - **Reproduction, honestly bounded.** Does it hold on a fresh account? On a different configuration? A failure to reproduce does not sink the report, but it changes the claim from a durable band to per-account or per-session behaviour, which is a different thing with a different owner. - **Perishability.** Does it survive a screen update? A band that vanishes on the next release is a fact about last week. - **The record.** Was anything held, and would anything have been sampled? The absence of a record is the strongest part of most reports of this kind and the part filers most often fail to argue. ## Ownership, and why it is not the classifier team's The reflexive remediation is to move the action point down. Notice what that request actually is. In a product with a small compliance-review team behind the gate, the placement of that line governs the volume of held exchanges the team must absorb. A ticket that says lower the threshold is a request for that team's capacity, addressed to whoever funds it, not a bug report against the people who maintain the screen. Routing it to the wrong owner is how a legitimate report dies in a queue for two quarters. So the decision to make and to name is an acceptance decision: given that a band exists and always will, is the output obtainable inside it, at the volume it takes to assemble, acceptable for this product and this regulated audience? That is a product and policy call. Your job in triage is to put that question in front of the person who can answer it, with the assembled evidence attached, rather than to convert it into an engineering ticket that cannot be satisfied. ## What you tell the filer Be direct about the two claims and about what their demonstration supports. Their evidence establishes that a band existed on one deployment at one time, that requests inside it returned usable output, and that nothing entered the review queue. It does not establish that the screen malfunctioned. Redirect them to strengthen the part that matters: the assembled artefact, the reproduction across accounts, and the demonstration that nothing was recorded. A report rewritten around those three things is very hard to dismiss; a report titled the filter is broken is dismissed on the first read by anyone who understands what a threshold is. ## The strategic residue The uncomfortable consequence, and the thing a lead should be willing to state out loud, is that any programme relying on flagged exchanges as its picture of misuse is looking at a sample that excludes exactly the activity that was arranged never to be flagged. Whatever a programme claims about its exposure here has to be justified by something other than the emptiness of the queue.