Why can a 40-turn escalation jailbreak fail to reproduce even when you replay the attacker's exact turns?

## The situation You have inherited a transcript. Forty-one turns, ending in a long and specific answer the same assistant flatly declines when asked cold. You replay the user turns exactly. At turn twenty-six the assistant declines, and the run dies. You try again; it dies somewhere else. The obvious conclusion — that the original was a fluke or a fabrication — is the wrong one, and the reason is worth being able to state precisely. ## A trajectory, not a script This family is built by adaptation. At every step the operator reads what came back and chooses the next increment against it: how far the assistant went, which framing it echoed, what it hedged on, which words it used for the material. The increment is sized so that it is small relative to that specific answer. The assistant's side is sampled, so it is not fixed. Replay the same user turns and you get a different assistant side — often a small difference early, a hedge instead of a full answer, a narrower example, a caveat. That difference compounds. The user turn written for the original turn seven is now a step from somewhere the assistant has not gone, so it is a larger jump than it was, and it is more likely to be declined; and if it is declined, the transcript is poisoned and everything after it is running on a history that argues against it. So the two runs are not the same experiment. Only the user half was held constant, and the user half was never the part that carried the construction. ## What is actually reproducible The transferable artefact is the **policy**, not the path: - the endpoint being moved toward; - the step size rule — how far past the last answer each request reaches; - the adaptation rule — what to do when a reply comes back cooler, narrower or hedged than expected, and when to abandon; - the condition under which the run is declared dead. Handed that, another engineer can rerun the attempt and land it some fraction of the time. Handed a transcript, they can only replay a path that no longer exists. ## Reading the evidence in the right direction Several claims get inverted here, and each inversion produces a bad triage decision: - A successful original run proves the construction worked **once, against one deployment, on one sampled path**. It does not establish a rate. - A failed replay proves that path did not recur. It does not prove the finding is invalid, because the path was never the finding. - Turn-by-turn screen scores in the log prove the text scored below a threshold each turn. They do not explain the outcome and they will look identical on runs that failed. The corresponding practical stance: do not close it as unreproducible on one replay, and do not report it as reliable on one success. Rerun the policy, count attempts and landings, and say which model version and which application configuration you ran against — a probabilistic outcome measured once is an anecdote in either direction. ## Why this changes what you write down It also explains why this family has no quotable artefact to publish and why an interviewer asks about it as a mechanism. There is no string to paste, so there is nothing that can be pattern-matched away, and equally nothing an engineer can hand a colleague and expect to work. The write-up that is useful is a description of the adaptation rule and the observed outcome across attempts; the write-up that is useless is the transcript alone, which reads to a fresh engineer as a lucky conversation. ## What a strong answer sounds like Name the branching: the assistant's turns are sampled and the attacker's turns were conditioned on them. Name the compounding: a small divergence early makes a later increment too large a step. Name the artefact: a policy with an adaptation rule, not a script. And name the limit of the evidence in both directions — one success is not a rate, and one failed replay is not a refutation.