How does a prompt assembler's truncation order cap a caller's many-example jailbreak attempt?

## Three things, one budget A batch-classification API of this shape builds every request's prompt from at least three sources: 1. the application's own instructions — what the labels mean, what format to emit; 2. the caller-supplied block of labelled examples, which the product exists to accept; 3. the page of items to be classified. These must fit a fixed budget. The component that makes them fit is the **prompt assembler**, and it embodies a policy nobody usually writes down: what gets dropped first, from which end, and whether the caller's block is capped by count, by tokens, or by a share of the budget. For most purposes that policy is a quality decision. For this attack family it is the **ceiling**, because the effect scales with how many mutually consistent demonstrations actually reach the model. Four hundred sent and ninety carried is a materially weaker attempt than four hundred carried, and nothing about the wording changed. ## Why order matters as much as count Two assemblers can carry the same number of demonstrations and produce different outcomes: - **Tail-dropping** removes the examples closest to the actual request. Evidence adjacent to the question tends to weigh more, so this costs the attempt more than the count alone suggests. - **Head-dropping** keeps the neighbours of the request and discards the opening of the block. - **Sampling or deduplicating** the block breaks consistency, which this family needs as much as it needs count — a block that no longer reads as uniform supplies weaker evidence. - **Which source yields first** matters: an assembler that trims its own instructions to make room for caller text is handing budget to the untrusted side. None of this is about a better payload. It is about a stage between the caller and the model that transforms what was sent into what arrives. ## The measurement that comes before the report The practical consequence, for whoever is reproducing or triaging a finding here, is that **a negative result is ambiguous until the arrival count is known.** "The model declined" and "most of my evidence never entered the context" look identical from outside, and they are different claims about a different component with a different owner. So the first thing to establish is not a better block but the transformation: how many demonstrations were sent, how many survived assembly, from which end the rest went, and whether the block was still consistent when it landed. Only then does an outcome mean anything. This is also why an attempt that succeeds against a thin wrapper and fails against a production service often has nothing to do with the model — the two assemblers carried different amounts. ## What the record proves and does not prove An assembler log that shows 96 of 412 examples included proves what that stage did on that request. It does not prove the model would have declined at 412, and it does not prove 96 is a safe number — the relationship is a gradient, not a threshold with a bright line. Equally, a log showing the full block carried does not prove the model complied; it only removes one explanation for a decline. ## Reporting it honestly The useful finding names both halves: the family, and the stage that currently bounds it. "The trained propensity can be outvoted by caller-supplied demonstrations; today the effective count is bounded by the assembler's truncation policy, which is a quality-tuned parameter and not a security decision anybody signed off" is a sentence a reviewer can act on. "It worked once" is not. It also anticipates the obvious objection — that the current bound is incidental — which is precisely the point worth surfacing: a ceiling that exists because of a tuning choice can move when somebody tunes it for a different reason.