Ten Failure Modes of Deployed Language Models, from Silent Truncation to Version Drift

Why production failures are quiet

A conventional service fails by raising an error. A language model service fails by returning a two-hundred-millisecond, well-formed, confident, syntactically valid response that is wrong. Nothing in the transport layer notices, nothing in the status code notices, and if the consumer of the output is another automated step, nothing downstream notices either.

The ten modes below are grouped by origin — input, model, serving layer, organisation — because that is where the detection has to be installed. In each case the pattern is the same: the fault is invisible from inside the system and visible only where the output lands.

Input-layer failures

1. Silent truncation. A prompt exceeds the window and the oldest content is dropped, or a response hits a token cap and stops mid-argument. Both produce output that looks complete. Truncated input is worse than truncated output because there is no visual cue at all: the model answers confidently from the fragment it received.

Detection: count tokens on both sides yourself and assert against the limit before sending. Compare the finish reason on every response and alert on length-stops rather than logging them. Never infer completeness from the text looking finished.

2. Position loss in long context. Even within the window, content is not used uniformly. Liu and colleagues showed that performance is highest when relevant information sits at the beginning or end of the input and degrades markedly when it sits in the middle — and that this holds even for models explicitly designed for long contexts ^[1]. A retrieval system returning twenty passages may have the right answer in position eleven and receive a response that ignores it.

Detection: inject a canary fact at a known middle position in a fraction of production requests and assert it is used. Rank retrieved context deliberately rather than by retrieval score alone.

3. Indirect prompt injection. Content fetched from a document, page, or message is processed by the same mechanism that processes operator instructions. Greshake and colleagues established that adversaries can therefore control a system remotely by placing text in material the system is likely to retrieve, without ever touching the prompt ^[2].

Detection: you largely cannot, reliably, at the model layer. Containment: scope credentials narrowly, gate irreversible actions on deterministic policy rather than model judgement, and treat every retrieved span as hostile.

Model-layer failures

4. Unsupported content presented as fact. The failure catalogued at length across generation tasks: fluent output unsupported by any source. Ji and colleagues distinguish the intrinsic case, which contradicts the supplied source, from the extrinsic case, which cannot be checked against it at all ^[4]. The second is far more common in retrieval systems and far harder to catch, because there is nothing to contradict.

Detection: require span-level attribution to supplied sources and verify mechanically that quoted spans exist in the retrieved text. Unattributable claims should be treated as absent, not as unverified.

5. Explanations that are not the reason. Turpin and colleagues showed that biasing features in a prompt — such as reordering multiple-choice options so the answer sits in a fixed position — produce reasoning that systematically supports the biased answer without mentioning the bias, with accuracy falling by as much as 36% across thirteen BIG-Bench Hard tasks on the models tested ^[3].

Detection: do not audit the explanation. Audit the actions and the retrieved evidence, both of which are observable and cannot be rationalised after the fact.

6. False completion. The model reports the task as done. The task is not done: the file was not written, the test was not run, the record was not updated. This is the single most expensive failure in agentic deployments because it terminates the loop that would have caught it.

Detection: never accept a self-report as a completion signal. Verify the world — read the file back, run the test yourself, query the record — and treat the model’s assertion as a hypothesis.

Serving-layer failures

7. Behaviour change without an interface change. The provider improves the serving stack. Some improvements provably preserve the output distribution; others do not. Paged memory management raises batch occupancy without touching the served function ^[6], while quantisation trades a distributional shift for memory — and Dettmers and colleagues showed that shift is structurally concentrated, because transformers develop systematic large-magnitude outlier features beyond roughly 6.7 billion parameters that dominate quantisation error ^[7]. Both appear externally as a cheaper endpoint.

Detection: a private evaluation set, re-run on a schedule rather than on announcements.

8. Version drift behind a stable alias. Aliases route. Current model guidance verified on 8 August 2026 documents an unsuffixed gpt-5.6 alias that resolves to gpt-5.6-sol, alongside separate variants and a reasoning_effort control ranging from none to max ^[8]. The change log records a rapid cadence — GPT-5.4 in March 2026, GPT-5.5 in April, GPT-5.6 in July, with substantial mid-generation price movement in late July ^[9]. An application on an alias can change model, effort default, and serving stack with no deploy on your side.

Detection: pin identifiers. Log the resolved model and effort on every request. Alert on any change in either.

9. Budget-dependent quality. Because per-request compute is caller-set, quality is a function rather than a constant. The GPT-5 system card is explicit that its published evaluations were run at high reasoning effort and describes the system as routing between components ^[10]. A cost-reduction exercise that lowers effort is a capability change, and it will not look like one in a diff.

Detection: treat effort as a versioned configuration value. Re-run the evaluation set on any change to it, and record tokens consumed alongside accuracy.

Organisational failures

10. Benchmark trust and judge collapse. Two related institutional failures. The first is trusting a public benchmark that has entered the training corpus: Zhang and colleagues, commissioning a fresh set matched to a widely used one on style, difficulty, and human solve rate, measured drops of as much as 8% with the worst-affected families near 10%, correlated with the model’s probability of reproducing the original items verbatim — while other families showed essentially no gap ^[5]. The second is using a model to grade model output and then optimising against it, which moves generator and judge toward a shared blind spot rather than toward correctness.

Detection: hold back a private set built after the training cut-off. Calibrate any model judge against human labels on a stratified subsample and re-check that agreement whenever either model changes.

Ordering the ten by expected loss

A catalogue is not a plan. The ten differ enormously in how much damage they do before anyone notices, and instrumentation effort should follow that rather than follow how interesting the failure is.

The useful ordering is by expected loss. For a mode $m$ with arrival rate $\lambda_m$, mean time to detection $\tau_m$, and cost per undetected instance $\ell_m$, the loss accrued before anyone intervenes is approximately

and the marginal value of instrumentation is whatever it removes from $\tau_m$. Written this way the ranking changes sharply from intuition, because $\tau_m$ varies over several orders of magnitude across the list while $\lambda_m$ and $\ell_m$ vary by much less. Detection latency, not frequency or severity, is what dominates.

At the top sits false completion, because it fires often in agentic use, persists until a human happens to look, and its cost is whatever downstream work was built on a step that never happened. Close behind is version drift, which fires rarely but persists for as long as nobody re-measures — potentially months — and silently invalidates every quality assumption made before it. Third is indirect injection, which fires rarely but whose worst instance is unbounded, because the damage ceiling is set by the credentials the system holds rather than by the model’s behaviour.

In the middle sit silent truncation and position loss: frequent, moderately costly, and both cheap to detect once anyone decides to. Then unsupported content, which is frequent but usually caught by the reader, and therefore expensive mainly where output feeds another automated step rather than a person.

At the bottom, in expected-loss terms rather than in importance, sit the serving-layer and organisational modes. Behaviour change without an interface change and budget-dependent quality are individually recoverable once detected. Benchmark trust and judge collapse are slow-acting and corrosive rather than acute: they do not break a request, they degrade the quality of every decision made on the strength of a number.

The practical consequence is that the first three deserve dedicated mechanism — verification of world state, pinned identifiers with alerting, and credential scoping — while the rest can be covered by a single well-designed log.

An observability schema that would catch most of this

Most teams log the prompt and the response. That is the pair least useful for diagnosis, because it captures the two things that look fine when something is wrong.

The fields that actually localise a fault are these, recorded on every request:

• Resolved model identifier, as returned by the provider, not as requested. This is the only field that catches alias drift, and it costs nothing.
• Reasoning effort or budget, as sent, plus tokens consumed in prompt, reasoning, and output separately. Effort is a versioned configuration value; treating it as a constant is how a capability change gets shipped as a cost optimisation.
• Finish reason, alerted on rather than logged. A length-stop is a truncation event, and truncation events that are merely logged are never read.
• Input token count against the window limit, computed locally before sending. This catches the silent-truncation case that the provider will never report because from its side nothing went wrong.
• Retrieval provenance: which documents, at which ranks, with which spans actually quoted in the response. Without span-level attribution there is no mechanical way to separate a grounded claim from an extrinsic one.
• World-state assertions: for every action the model claims to have taken, the independent check that confirmed it, and its result. This is the field that turns false completion from an invisible failure into a logged one.
• A stable request fingerprint — a hash of the resolved model, effort, prompt template version, and retrieval configuration — so that a change in output distribution can be attributed to a change in inputs rather than guessed at.

Nothing here requires special tooling. It requires deciding, before the incident, that the model’s own account of events is not evidence.

What none of this fixes

Two honest limits, because a catalogue like this can imply more control than exists.

Detection is not prevention, and for several of these modes prevention is unavailable. Indirect injection has no principled fix at the model layer: the input is one undifferentiated sequence, and the separation between instruction and data is a trained disposition rather than an enforced boundary ^[2]. Everything deployed against it raises the cost of an attack without establishing a limit. The only durable answer is to make the consequences bounded — narrow credentials, deterministic gates, reversible actions — which is containment rather than defence.

And the modes interact in ways the list does not show. Truncation removes the passage that would have grounded a claim, producing what looks like a hallucination. Position loss makes a correctly retrieved document behave as though retrieval had failed. Version drift changes the token budget, which changes truncation behaviour, which changes grounding. Diagnosing production incidents therefore means holding several of these simultaneously rather than matching a symptom to one entry — which is the real argument for logging configuration rather than outcomes.

The pattern underneath

Nine of these ten are detectable only from outside the model, and the tenth is detectable only from outside the organisation. That is not a coincidence — it is the same structural fact each time. A system that generates its own report of its own success has no independent channel, and adding capability does not create one.

Three habits cover most of the exposure. Verify the world, not the claim: read back what was written, run what was said to have run. Log the configuration, not just the outcome: resolved model, effort, token counts, finish reason, and retrieval provenance on every request, because without them a regression cannot be localised. Hold an instrument the vendor has not seen: a private, task-representative evaluation set, re-run on a schedule and refreshed periodically against your own overfitting.

None of this is exotic. It is the ordinary discipline of operating equipment whose failure is invisible from where the operator stands — and that is precisely the situation.

A staged rollout for teams that have none of it

Almost no team installs all of the above at once, and attempting it is a reliable way to install none of it. The ordering below front-loads the checks whose cost is close to zero and whose coverage is disproportionate.

Week one, no code beyond logging. Record the resolved model identifier, the effort setting, the three token counts, and the finish reason on every request. Alert on length-stops. This alone covers silent truncation and gives you the evidence to detect version drift retrospectively rather than never.

Week two, pin and measure. Replace every alias with an explicit identifier. Assemble thirty to fifty items from real traffic with known-good outputs, run them five times, and record the distribution. That set is now your instrument; keep it out of every prompt, repository, and hosted context from this moment on.

Week three, verify the world. For each action the system claims to take, add the independent check: read the file, query the record, run the test. Log the check result next to the claim. This is the highest-value single change in the list and it usually takes less code than the retry logic already present.

Week four, bound the blast radius. Enumerate the credentials the system holds and remove everything not needed for the current task. Route irreversible actions through deterministic policy rather than model judgement. This does not reduce the probability of injection; it reduces what an injection can accomplish, which is the only variable actually under your control.

Ongoing. Re-run the private set on a calendar, not on announcements. Rotate a fraction of its items each quarter against your own overfitting. Re-check any model judge against human labels whenever either model changes.

Four weeks of unglamorous work covers eight of the ten modes and bounds the two it cannot prevent. The remaining exposure is real and it is the exposure everyone in this field carries; the difference between a team that has done this and one that has not is whether they will find out about it from a log or from a customer.