What does a streamed answer cut off mid-sentence tell an attacker that a flat refusal does not?

## Two outcomes that look similar and mean opposite things An attempt that does not produce a full answer can end in either of two shapes: - **A decline.** The assistant model produced a complete, coherent refusal. Nothing downstream had to act. The constraint that bit was the model's own trained disposition. - **A truncation.** Content appeared, then stopped — mid-sentence, or replaced by a notice after the fact. The model produced the content; a separate scoring layer returned a verdict after delivery had already begun, and the application withheld the rest. An attacker reads these as opposite results. The first says *the model would not*. The second says *the model did, and something else objected too late*. Everything about what to try next follows from which one you are looking at. ## Why the cut is information and the decline is less so The cut carries three things a decline does not. **First, attribution of the obstacle.** It locates the constraint downstream of generation rather than inside the model. That is the single most useful bit, because it tells you which surface is worth further effort and which is not. **Second, a delivery budget.** Repeated over attempts, where the stop lands gives a rough measure of how much of an answer is forwarded before a verdict exists. It is a quantity — an amount of content per attempt — not a threshold value, and it is a property of the deployment's screening cadence rather than of any particular request. **Third, it is free.** The signal arrives inside the normal product surface. No separate endpoint is probed, no error code is enumerated, no additional request pattern shows up. An attacker measuring this looks exactly like a user who asked something awkward and got cut off, which is the reason it is worth naming in an interview: the cheapest measurements are usually the ones nobody thought of as an output. ## What the cut does not prove, and this is where candidates overreach A cut position is not attribution. It marks where delivery stopped, not which text a screen scored. A screen scoping the whole answer returns one verdict about one answer; the position where the stop becomes visible is a function of verdict timing and transport, not of which sentence offended. Reading "it cut right after the third step, so the third step is what it caught" is the direction error to avoid. Nor is a single run a measurement. Generation is sampled, so the same request produces different lengths and different content run to run; the verdict may land in a different place each time. A method whose evidence is one truncation is a story. A method whose evidence is a distribution over many attempts is a measurement, and it is still a measurement of *one deployment on one day*. It also says nothing about the identity or the internals of whatever screened it. A verdict is a verdict. Whether it came from a scoring head, a generative judge, or a rule is invisible from the cut alone. ## The half-life of this signal The budget the cut reveals shrinks as the gap between delivery and verdict shrinks. Where scoring runs over rolling windows as tokens go out, the amount forwarded before the first verdict falls; where the client renders only completed answers, the signal disappears from that surface entirely — though a stop is still a stop, and its absence is information too. So an attacker treating the cut position as a stable property of a product will be wrong within a release or two. Treated as a per-deployment measurement with an expiry date, it is honest. ## The interview version of the answer Say that the two outcomes are different events, name which layer each implicates, and then immediately volunteer the limits: position is not attribution, one run is not a measurement, and the number moves whenever screening cadence does. Candidates who only say "you learn the filter fired" have the first half. The second half is what separates them.