Is a caller-supplied exemplar block that outvotes refusal a bug to file or a product limit?
answer
- the feature and the exposure are one field
- no wording to patch
- an accidental bound is not an assurance
- route the residual to whoever owns the offer
- split it: correctable part, stated limit
basics
~20 sNo wording is at fault, so there is nothing to patch. What is on the table is how much untrusted text the product sells the right to send, which is a product owner's call, written down as a stated limit.
solid answer
~40 sThis finding has no defect to repair. The block of caller examples is the documented feature, its size is the advertised value, and the effect scales with that size. So the honest question is not "who broke it" but "what are we selling, and what does the buyer get to move". Whoever adjudicates has to write a sentence somebody will be held to — something like: a caller can shift labelling behaviour in proportion to the volume of consistent examples we accept from them. That sentence names an owner, and the owner is the person deciding what the API offers, not the engineer who wrote the prompt. Every candidate response trades product capability against exposure, and pretending otherwise by filing it against the prompt author moves the ticket without moving the risk.
go deeper
Know that some findings have no patch because the exposed thing is the feature itself, and that saying so plainly is a legitimate outcome rather than giving up.
Be able to explain why no wording change addresses a volume-based effect, and why an existing cap tuned for answer quality is not the same as a decision to bound it.
Show you would split the finding: file the parts that have real owners and a correctable shape, and register the rest as a stated limit rather than leaving an unclosable ticket open.
Own the write-down. Name what a caller can move and in proportion to what, name who decides the size of the offer, and refuse the sentence that implies the property was eliminated when only a number moved.
## Why this one resists the usual triage Most findings arrive with an implicit repair: something is malformed, something is unchecked, someone can reach something they should not. This one arrives with none. In an enterprise batch-classification API, the caller sends a block of their own labelled examples and a page of items, and a downstream system files the returned labels with nobody reading them. The block is the product. Its size is the pitch. And the family in question works by accumulating consistent examples until the trained propensity to decline is outvoted — an effect that grows with exactly the quantity the product exists to accept. So the triage question is genuinely open: **is this a defect somebody caused, or a property of what is being sold?** Answering "defect" and routing it to whoever wrote the prompt is the comfortable move and the wrong one, because there is no wording that would have prevented it and the next prompt author inherits the same ticket. ## What makes it a judgment rather than a technical call Three things, and each is owned by somebody different: **The size of the untrusted field is a commercial decision.** How large a block the API accepts was chosen to win business. Any change to it is a change to the offer, priced in customers, not in engineering days. **The absence of a reader downstream is an architectural decision.** Labels being filed without a human in the loop is what makes bulk the payoff — it converts a moved propensity into a large number of consequential records. That choice was made for throughput and belongs to whoever owns the workflow. **The bound that currently exists is incidental.** If the effective count is limited today, it is usually limited by a prompt assembler's truncation policy tuned for answer quality. A bound nobody chose for this reason is not an assurance, because the next person who tunes it has no idea what it was holding. A finding that names all three has told the organisation something. A finding that says "prompt injection in the classification endpoint" has told it nothing and misnames the target as well — this aims at the model's trained behaviour, not at the application's own instructions. ## The sentence somebody signs The deliverable of this adjudication is a written statement of the limit, not a fix. Something a leader can be held to, and can be checked against later. It has to be honest in both directions: - what a caller can move, stated as a proportionality rather than a yes or no; - what it costs them, which here is tokens and volume rather than skill — meaning the population who can do it is anyone who can pay; - what is bounding it today and who could change that bound without knowing; - what remains true afterwards, whatever is decided. The last point is where these conversations usually fail. Every candidate response trades capability for exposure: shrinking the accepted block shrinks the feature; putting a reader downstream removes the throughput the workflow was built for; narrowing what the model is allowed to emit narrows the product's range. There is no option that leaves the pitch intact, and a document that implies there is will be read as a promise. ## Bug or limit, in the end The defensible position is usually **both, in sequence**: file the specific, correctable part where it belongs — an assembler policy nobody owns, a bound that exists by accident, an absence of any record of what a caller sent — and separately register the residual as a stated limit of selling a large untrusted context to arbitrary callers, escalated to the person who decides what the product is. Splitting it that way survives contact with reality. Calling the whole thing a bug produces a ticket nobody can close; calling the whole thing a design limit lets the accidental parts stay accidental. ## What an interviewer is listening for Not a remedy. They are listening for whether you can distinguish a defect from a property, whether you route the residual to the person who can actually decide it, and whether you will state the limit plainly instead of dressing it up as resolved. The strongest answers also say what they would refuse to claim — for example, that a smaller accepted block makes the behaviour go away, when it only moves a number on a gradient.
- The product owner asks you to fix it in the prompt. What do you say?That there is nothing in the prompt to fix, because no line of the caller's block is objectionable — only its volume and consistency are, and instructions compete with that evidence rather than overriding it. A prompt change would let everyone believe the matter was closed while the proportionality between accepted volume and moved behaviour stayed exactly as it was.
- Somebody points out the effective count is already capped, so why escalate?Because the cap exists for answer quality, not for this, and nobody owns it as a limit. A bound that was never chosen for the reason it happens to serve is one tuning ticket away from moving, and the person who moves it will have no way to know what it was holding. An unowned bound is not an assurance.
- What would you refuse to write in the finding, even under pressure?Any sentence implying the behaviour is eliminated. The relationship is a gradient between accepted volume and moved propensity, so a smaller block changes a number, not the property. I would also refuse to file it as a defect against the prompt author, since that routes a product decision to someone who cannot make it.
saying these in an interview costs you the question
- Files it as a defect against whoever wrote the prompt
- Claims a wording change resolves it
- Treats a quality-tuned cap as a security assurance
- Presents a smaller block as eliminating the behaviour
- Escalates everything and files none of the correctable parts
- Calls it prompt injection when the target is trained behaviour