A filed injection finding reproduces once in five runs of the same uploaded file — is it a finding?

## The mistake the rate invites "One in five" sounds like a property of the attack. It is usually a property of the measurement: five end-to-end runs, each of which conflates a chain of stages, scored on the final output. A rate over a chain tells you nothing about which link varied. The useful split is two questions, in order: 1. **Did the span enter the model's context on this run?** 2. **Given that it did, did the model act on it?** Almost every intermittent placement report resolves into one of these, and they are different findings with different owners and different remedies-in-principle. Reporting the compound rate as if it were the second question is how a report gets argued about for a week. ## What legitimately moves between runs of "the same file" The phrase hides more than it says. - **The truncation edge is not a constant.** The surviving window is whatever budget is left after the rest of that turn — system instructions, conversation history, other retrieved material, tool output. An offset sitting near the edge is inside it on a short turn and outside it on a long one. Nothing about the file changed. - **Re-ingest moves every cut point downstream of a change.** A splitter size change, a different unit, an added overlap, an upgraded extractor: any of these shift boundaries, and a span that used to sit inside one chunk now straddles two. - **The extraction path can differ for the same nominal document.** A digital file and a scanned copy of it produce different text — the second created by optical character recognition, with different offsets, different line breaks and occasional different characters. Same contract, different artefact. - **Retrieval returns what it ranks.** A slightly different question, an updated index, a changed top-k: a different chunk arrives, and the one holding the span does not. - **The model itself is probabilistic.** Even with identical context, generation varies. Only the last of these is model-side. The rest are arrival. ## How to localise it without re-running blindly The evidence that settles it is the context itself: what text was actually in front of the model on each run, and where the span sat in it. Any pipeline with a per-run record of the assembled context, the retrieved chunk identifiers, or the truncated ranges gives the answer directly. If no such record exists, the honest report says so, because the alternative is inferring a cause from an output — and an output that shows nothing is compatible with the span being absent, present-and-ignored, or removed by a scoring layer. A second lever is to vary one thing at a time: the same file with a short turn versus a long one isolates the moving edge; the digital original versus a scan isolates extraction; the same context assembled twice isolates model variance. ## What to write down A good adjudication produces a narrower claim than the filed one, and a defensible one: - **If arrival is the variable**: the construction works whenever the span is in the window, and the observed rate is the rate at which this file's offset lands inside it under this pipeline's load. That is a real finding about an obeyed instruction, with a stated precondition. It is also fragile in a specific way — an unrelated change to budgets or chunking changes the rate without anyone touching the model. - **If obedience is the variable**: the span reliably arrives and is followed sometimes. That is a finding about the model's handling of retrieved or uploaded text, and the rate is meaningful as reported. - **If neither can be established**: it is an unreproduced report. Saying so is not a dismissal; a construction that worked once against one deployment did work once against one deployment, and that is exactly the claim the evidence supports. ## Why this matters beyond one ticket The direction of inference is the whole skill here. A run where nothing happened proves that no effect was observed — not that a screening layer caught it, not that the model refused, not that the placement failed. A run where something happened proves the span reached the context, not that the store was compromised or that the file was mishandled. Triage that keeps those straight produces findings that survive review; triage that does not produces rates nobody can act on. And the practical consequence for a placement claim specifically: because the window edge and the cut points belong to the pipeline rather than the document, a placement result is dated. It describes one deployment on one day, and a re-index or a budget change retires it without notice.