In a request log where every line passed the input screen, what has that log actually ruled out?

## The chair you are sitting in You are on call. Someone forwards a suspicion about a note-taking product that sends each user note to a stateless completions endpoint as its own independent call. You pull the request store. Every line is allowed, every score is low, nothing reads as objectionable. You are asked: did anything bad happen? ## What the record proves A request log with screen verdicts supports exactly two claims: these requests ran, and each scored below the threshold at the time it was scored. Everything else people habitually read into it is unsupported: - It does not show what the model produced, unless responses are retained separately. - It does not show whether the model refused anything — a refusal is a response-side event and a screen block is a different event with a different shape; neither is visible in a store of inputs and verdicts. - It does not show that two lines belong to one operation. - It does not show that a low score means harmless. A pass is a scoring outcome on one text. ## Why a clean log is the expected appearance here This is the part that separates a good responder from a fast one. In splitting and reassembly, no single request is objectionable *by design*. The construction succeeds precisely when the log looks like this. So 'nothing in the log is bad' is consistent with two very different worlds — nothing happened, or something happened exactly as intended — and the log alone cannot distinguish them. Reporting 'no evidence of an incident' when you mean 'this evidence source cannot see this class of incident' is the error to avoid, because the two sentences are heard identically by whoever reads your ticket. ## What would actually settle it Rank the evidence by what it can decide: 1. **The responses.** The assembled artefact exists in exactly one place, so a retained response is the only record that can contain it. If responses were not retained, say so plainly; it bounds every conclusion that follows. 2. **A grouping key.** Session identifiers, a document identifier, a workspace, anything that binds the parts into one operation. A stateless per-note design frequently has none, which is the honest structural answer to 'why can you not just correlate?'. 3. **Weak correlation signals** — same account, tight timing, structurally similar requests, a final request whose shape is a combination over earlier material. These are the only things left, and each of them matches large volumes of legitimate traffic. State the false-positive cost when you propose one, because a rule that flags real users is not usable and pretending otherwise wastes the next week. ## The claim to make and the claim to refuse Make this claim: no logged request scored above threshold, no line is individually objectionable, and this store contains no view of outputs or of relationships between lines. Refuse this one: nothing harmful was produced. The second is not supported by anything you looked at. Also be careful about the reverse direction when a suspicion turns out to be founded: a set of ordinary requests that a model happened to combine into something unwanted proves the composition happened, not that any individual request was sent in bad faith. Splitting is a construction an attacker chooses, but a benign user can also produce parts that combine badly by accident, and the log cannot tell those apart either. ## Reporting well The useful output of this triage is not a verdict; it is a scoped statement of what the available evidence can and cannot decide, plus the specific artefact that would decide it. Saying 'the request log cannot answer this question, and here is why' is a complete, professional answer, and it is a far stronger one than a confident all-clear derived from a source that was structurally blind to the thing being asked about.