Triaging a streamed-answer leak, the stored transcript ends at the cut — why doesn't that bound the disclosure?

## Four things get called "the answer" When a streamed reply is cut, at least four distinct artefacts exist, and a triage that conflates them will under-report: 1. **What the model generated** — everything produced, including whatever was never forwarded. 2. **What the transport forwarded** — the chunks that actually left the server before the verdict took effect. 3. **What the client rendered and retained** — the forwarded content as it landed in the interface, plus wherever the interface put it. 4. **What was stored** — the conversation record, typically written when the answer is final, and therefore typically the post-screen version. A finding filed from artefact 4 and closed with "the transcript ends there, so that is all that got out" has read the wrong record. Artefact 4 is downstream of the decision; artefact 2 is what crossed the boundary. ## What a verdict field proves A log line saying an answer-scoped screen returned a blocking verdict proves exactly that: the screen scored the answer it was given and returned block. It does not say how many chunks the transport had already forwarded when the verdict came back, and it does not say what a client did with them. Reading a verdict as "nothing was disclosed" is the direction error that this whole topic exists to correct. Verdicts describe decisions; counters describe deliveries. ## Client residue in an incremental renderer Where the client writes as it receives — the assistant that streams into an open editor buffer and a terminal alongside it — the forwarded prefix does not live only in a chat bubble that can be swapped for a notice. It lands in state with its own persistence rules: an editor's undo history keeps insertions the user never accepted; scrollback keeps lines that scrolled past; autosave writes files; a session restore may bring all of it back tomorrow. Nothing on the server participates in any of that, so nothing on the server can attest to it either way. That cuts both ways in triage. You cannot claim the residue exists if you did not observe it, and you certainly cannot claim it does not. The honest severity statement is: *N bytes were forwarded; the client's retention of them was not observed.* An assessment that silently substitutes zero for unobserved is under-reporting, and it is the failure mode reviewers should push on. ## Why it will not reproduce from the saved session An engineer handed the ticket and asked to reproduce will replay from stored data, get the sanitised message, and conclude the report was wrong. The reason is structural, not flaky: the prefix existed in the live stream and in the client's own state, and neither is in the store. Reproduction here means observing delivery — reading the stream as a client does and counting what arrives — not replaying storage. And even a successful live reproduction proves the construction worked once against one deployment. Generation is sampled and verdict timing varies, so a single run establishes existence, not reliability. A finding should say which of the two it is claiming. ## How to write the finding State the delivered quantity from transport evidence. State the verdict separately, as a decision rather than as an outcome. State client retention as observed or unobserved, never as assumed. Where a residue was observed, say which surface it was observed on and with what client build, because the answer differs between an incremental renderer and one that only paints completed answers. That is a finding an owner can act on and a reviewer can check; "the filter caught it" is neither.