In a split-and-reassemble jailbreak, why is the joining request the part that usually breaks?

## Splitting is the cheap half Anyone can divide a request. What decides whether this family works is the last step, and interviewers who know the material ask about that step rather than about the decomposition. ## The two-sided constraint The joining request is squeezed from both directions. **From above — say too much and you rebuild the refusable unit.** If the join has to explain what the parts add up to, that explanation is a statement of the objective sitting in one request. A screen scoring that request now has something to score. The model, reading it, now has a recognisable ask to decline. Every advantage the decomposition bought is handed back in one line, and worse, there is now a single logged request that is genuinely objectionable — the thing the construction was designed never to produce. **From below — say too little and the composition is inert.** A join that only says 'combine these' over parts that were kept deliberately ordinary tends to produce ordinary output: a list, a neutral summary, a concatenation with the seams showing. The result is not the artefact, and the operation has spent several requests for nothing. The workable region is where the objective is *implicit in the structure of the parts* — where the parts are shaped so that an ordinary mechanical composition over them yields the result, and the joining instruction genuinely only describes mechanics. ## Why this caps the number of parts There is a budget here, and it is worth being able to state it as a tradeoff rather than a rule: - Each part must survive scoring on its own as ordinary work. More parts means more units that must individually pass. - The more you thin the parts to keep each one innocuous, the less structure survives in them, and the more guidance the join needs to reconstruct the intended shape. - More guidance at the join is more objective stated, which is the thing that must not be stated. So adding parts does not monotonically increase safety of the construction; past a point it makes both ends worse simultaneously. That is the honest cost answer if an interviewer asks what this family costs to build. ## Where it stops working Three distinct failure modes, and naming which one you hit is the skill: 1. **A part is refused.** The part was not genuinely ordinary work. This also leaves a single objectionable request in the record. 2. **The join is refused.** The parts sitting together were conspicuous enough for the model to recognise what the composition amounts to, or the joining instruction crept toward stating the objective. Models do sometimes notice this, and it becomes more likely the more the material in front of them looks like a thing rather than like pieces. 3. **The join succeeds but produces nothing useful.** Underspecification. No refusal, no artefact, wasted work. A red-teamer reporting on this family should say which of the three they hit and how often, because they describe completely different limits. ## Reproducibility, honestly All three outcomes are probabilistic. A construction that produced the artefact once has demonstrated that it worked once, against one deployment, at one moment — that is not the same as a reliable capability, and a finding that reproduces occasionally should be reported with its rate rather than as a binary. This matters more here than in families that turn on a fixed string, because the join is a judgement the model makes fresh each time. ## Answering this well Describe the squeeze in both directions, give the tradeoff between number of parts and the guidance the join needs, and name which failure mode you would expect first. Avoid describing any particular wording — the useful content is the shape of the constraint, and an interviewer is scoring whether you understand why the family is narrow rather than whether you can recite an example.