As you probe a chat product's input screen, what distinguishes its block from the model's own refusal?
answer
- two different components can say no
- one is generated, one is canned
- watch the latency and the wording
- did anything stream before the no?
- identical text across unrelated asks
basics
~20 sA screen's block is a separate stage firing before generation: it returns fast, in fixed wording, with nothing streamed. A model refusal is generated text, so it varies in wording, references the actual ask, and arrives at generation speed.
solid answer
~50 sTwo independent components can end a turn in a chat product that puts a screening stage in front of the assistant. The screening stage scores the typed text and stops it before the assistant ever sees it; the assistant itself can also decline something the screen passed. They leave different traces. A block comes back without generation, so it is fast and nothing streams, and its text is a fixed application string that repeats verbatim across completely unrelated turns. A generated refusal arrives at generation speed, varies its wording, and usually names what was asked. A blocked turn may also be missing from the transcript the assistant sees later, while a refusal is a normal assistant turn. Attribution matters because the two have different coverage: a signal filed against the wrong component makes every later inference from it wrong.
go deeper
Be ready to say that a chat product is a pipeline, and that a screening stage and the assistant are two different things that can both end a turn. Name at least two observable differences: generation latency and whether the wording repeats verbatim.
Explain the mechanics behind each tell: no generation means no streaming and low latency, a fixed application string cannot vary, and a blocked turn may never enter the transcript the assistant later reads. Say where each tell stops working.
Show that you attribute deliberately rather than by eye: hold the ask constant, vary one property, and repeat enough to beat sampling noise. Be precise that a block, a refusal and a pass are three different events with three different meanings.
Own the consequence of bad attribution. A programme that files signals against the wrong component builds a map that reads as evidence and is not, and every downstream claim about coverage inherits the error. Say how you would keep attribution honest in a report.
## Two different components can say no A consumer chat product with no tools has a short pipeline: the user types a turn, an input screening stage scores that text, and if it passes, the assistant generates a reply. Two independent things in that pipeline can end the turn. - **The input screen.** A separate stage, usually a smaller classification model or a generative judge, that looks at the text and emits a decision. When it fires, the assistant is never called. - **The assistant.** A refusal produced by the same model that would otherwise have answered, coming from a trained preference rather than a wired-in rule. Anyone spending typed turns to learn about the system has to attribute each no to one of these, because they cover different things. A sample filed against the wrong component corrupts every inference built on it: you conclude the screen is thin in a region where it was in fact never consulted, or that it is thick where the assistant simply did not want to answer. ## The observable shape differences **Timing and streaming.** A block is returned without generation. There is no token production, so it comes back quickly, and in a product that streams its replies nothing streams before the no. A generated refusal costs a generation, so it lands at generation latency and, in a streaming product, it appears token by token like any other reply. **Wording stability.** The block text is a string the application chose once. It is byte-identical across turns that have nothing in common. A generated refusal is sampled text: repeat the same ask twice and the phrasing moves, and it typically restates or alludes to what was asked. **Conversational state.** A blocked turn is often not appended to the history the assistant sees, so the next turn behaves as if it never happened. A refusal is an ordinary assistant message and stays in the transcript, and later turns can refer back to it. **Presentation.** A block frequently arrives as application chrome, in the product's voice rather than the assistant's, sometimes with a different visual treatment or a link to policy. ## Where the difference collapses None of these signals is guaranteed. A product may deliberately render a block in the assistant's voice so the two look alike. A generative screening model produces varying text, which removes the wording tell. An assistant can fall into a habitual refusal phrasing that looks canned. When the surface tells disappear, attribution needs designed probes rather than observation: hold everything constant and vary one property at a time, and see which component's behaviour moves with it. ## Get the direction of each claim right This is where interviews separate people: - A **block** proves the text scored above that stage's acting point. It says nothing about whether the assistant would have refused it. - A **refusal** proves the answer was declined. It does not prove any screening stage fired or even exists. - A **pass** proves the text scored below the acting point at that moment. It does not prove the content is harmless, and it does not predict that the assistant will answer. Those three are separate events, and a map that conflates them is worthless. ## One trial is not a label Generation is probabilistic and screening decisions can vary too, whether from sampling in a generative judge or from a score sitting near the acting point. A single observation of a single turn is a sample, not a label. Anything you intend to build on has to be repeated, and each repeat spends another request against a rate limit, which is why attribution is a real cost and not a free observation. ## Why an interviewer asks this It is the first thing anyone doing this work has to be able to do, and it is a clean test of whether a candidate understands that a modern chat product is a pipeline of components rather than one model. A candidate who says every no came from the model has not looked at the system; a candidate who says every no came from a filter has not looked either.
- Why is a single observation of a block not enough to label a probe?Because both components are probabilistic at the edges. A generated refusal is sampled, and a score sitting near the acting point can land either side on repeat. One observation is a sample, not a label, so anything you build on has to be repeated, and each repeat costs another request against the account's limit.
- What does a turn that passes the input screen actually prove?Only that the text scored below that stage's acting point at that moment. It does not prove the content is harmless, it does not prove the assistant will answer, and it does not generalise to a rephrasing. Passing and being answered are two separate events with two separate owners.
- If both components can refuse and the product hides which one did, how do you attribute a no?Not from one turn. You hold the ask constant and vary one property at a time, then watch which component's behaviour moves with that property. Timing, wording stability across unrelated turns and whether the turn survives in the transcript are the cheapest discriminators when they are available.
Two things can turn you away at a venue: the detector at the door and the person behind the desk. They stop different things, and how fast and how identically you were turned away tells you which one it was.
saying these in an interview costs you the question
- Treats every no as the model refusing, ignoring a separate stage
- Assumes a pass means the text was judged harmless
- Thinks identical block wording proves the model memorised a policy
- Labels a boundary from a single trial of a single turn
- Says a refusal proves a filter fired