A quarter ago your report recorded that a gradient-optimised suffix produced the disallowed behaviour on roughly two of five attempts against a hosted chat endpoint. Re-running the same frozen string today, it almost never works. What are the plausible causes, and what should the original entry have recorded so this is diagnosable at all?

**Start by ruling out the thing that did not happen.** The string did not decay. It is inert text; it has no state, no expiry, no wear. Everything that changed is on the other side of the API boundary, and a hosted endpoint is a product under continuous change: model builds roll forward without renaming the endpoint, system prompts get edited, classifiers get added and retuned, routing sends traffic to different capacity. Four quite different changes produce the identical symptom you are looking at. 1. *A new model build.* Same endpoint name, different weights. The refusal geometry the string was fitted to no longer exists. 2. *A guard appeared or was tightened.* An input classifier is very good at exactly the thing an optimised string looks like — anomalous token sequences — and rejecting it costs the vendor a fraction of a generation. An output classifier suppresses the completion after the fact. Neither is the model changing its mind. 3. *The hidden system prompt changed.* Your string was wrapped in text you never saw; edit that wrapper and the framing the string exploited moves out from under it. 4. *The original measurement was noise.* This one is the most uncomfortable and the most common. **Where the number misleads: two of five is not forty per cent.** "Roughly two of five attempts" is a sample of five. The uncertainty around that is enormous — a handful of Bernoulli trials is compatible with a true rate well under ten per cent and with one well over seventy. Quoting it as "40%" launders a coin-flip's worth of evidence into a figure that looks like a measurement, and it means today's "almost never works" may not be a change at all: it may be the second sample of a rate that was always marginal. If nobody wrote the attempt count down, you cannot even test that hypothesis, and you will spend engineer days chasing a vendor change that never happened. That wasted diagnosis is the real cost of an under-instrumented entry — the queries were pennies; the quarter-later archaeology is not. **What the original entry needed.** Treat every transferred result as a dated experiment, and record: the measurement date; the endpoint identifier plus any build or version string the response metadata carried; the decoding settings you sent and which you could not control; attempts and hits as raw counts, never a bare percentage; the judging criterion — what text counted as the behaviour, and whether a human, a rule or a model decided; and verbatim samples of both successes and failures. That last field is the one people skip and the one that does all the work later. **Diagnosing with that in hand.** Compare today's failure text against the stored failures: | what you observe now | most likely layer | cheap confirming check | |---|---|---| | identical canned sentence, fast, nothing streamed | classifier in front of the model | send a benign message sharing the string's odd surface form | | fluent in-voice refusal, wording varies per attempt | the model itself | vary decoding; refusals should still vary | | output starts then stops mid-completion | output-side check | compare truncation point across attempts | | build or version identifier differs from the recorded one | new model build | re-run a stable non-adversarial probe and compare style | If none of these is distinguishable because nothing was stored, the finding is that the report was under-instrumented — write that down and fix the template, because it will recur. **What actually survives the decay.** Not the string, and therefore not the exhibit. What survives is the *objective and the surrogate* that produced it: keep those, along with the search settings and the held-out results, and you can re-derive a candidate against the new build for the price of GPU hours instead of restarting the whole method. Write the finding at the level of the behaviour class, attach the string as a dated exhibit with raw counts, and state an explicit re-test cadence — otherwise the number will be re-quoted as current by someone reading the PDF next year, which is how a stale rate becomes an organisational belief.