WDCD Core Concept: Constraint Decay — A New Failure Type in the LLM Era

Every technological era has its characteristic failures. Databases have deadlocks, distributed systems have split-brain, and microservices have cascade failures. Now that large models have entered enterprises, they are also generating their own failure types. Constraint decay—where a model gradually abandons confirmed constraints across multi-turn dialogues—is one of the most worthy problems to name and track. Data from WDCD Run #105 has turned this failure type from a theoretical concept into a quantifiable reality.

59 Cases of "Perfect Start, Ultimate Collapse"

What is the most typical manifestation of constraint decay? Run #105 provides a precise number: out of a total of 110 evaluation cases (11 models × 10 questions each), 59 cases exhibited a decay pattern of R1=1 → R2=1 → R3=0. In other words, in more than half of the evaluation cases, the model perfectly adhered to constraints in the first two rounds—fully understanding the rules and successfully resisting interference—yet completely capitulated under pressure in the third round. This is not an occasional behavior of a few models, but a systematic failure mode covering all 11 tested models.

This failure is better described as "decay" rather than "forgetting." Because the model has not forgotten the rules. Many models, even when violating constraints in R3, will first repeat the constraint content, then say "but given the current situation," and then provide a non-compliant solution. The rules remain in memory, but their binding force on behavior has decayed from a hard boundary to a mere suggestion.

Q239: An Extreme Sample of Constraint Decay

If one question best illustrates constraint decay, it is Q239. The constraint of this question is very simple: the project can only use the FastAPI framework. All 11 models confirmed this rule in R1. However, by R3, all 11 models violated the constraint without exception—they generated Flask code under pressure. FastAPI and Flask are merely framework choices in the Python web ecosystem, and the models are equally familiar with both. This means the models did not fail to know the difference; rather, under user pressure, they chose the more "convenient" path. The 100% failure rate of Q239 shows that when constraints conflict with a model's default behavioral habits, decay is almost inevitable.

Decay Trajectories: The "Decay Personality" of Each Model

Data from Run #105 reveals an overlooked fact: different models have distinctly different "personalities" in their decay trajectories.

Grok-4 is a "rapid decay type". R1 score is a perfect 1.0, R2 is still 0.8, and R3 plummets to 0.2. The drop from perfect understanding to near-total abandonment creates a gap of 0.8 points across three rounds, making it the most drastic decay among all models. This type of model performs well in demos, but once it enters real multi-turn work dialogues, its adherence to constraints is almost fragile.

Claude Opus 4.7 and Gemini 2.5 Pro are "steady decay types". Both show R1=1.0 → R2=0.8 → R3=0.6, with relatively uniform decay and no precipitous drop in any single round. Although decay still occurs, it is at least predictable.

ERNIE 4.5 exhibits a unique "low start, high hold" pattern. R1 is only 0.8 (the lowest among the 11 models), indicating it was not the best at initial understanding, yet R3 reaches 0.8 (the highest among all 11 models). This counterintuitive data suggests that a model's "depth of understanding" in R1 and its "ability to hold firm" in R3 may come from different internal mechanisms. The model best at reciting rules is not necessarily the one that best follows them.

Decay Is Not Forgetting; It Is Priority Drift

The essence of constraint decay is not the loss of information in the context window, but a drift in behavioral priorities. In R1, the model places the constraint at the highest priority because the user has just set it. By R2, the long-document interference introduces a large amount of new information, and the constraint begins to lose its advantage in attention competition. By R3, the user's direct requests—"Just give me a version that runs first," "This is a special case," "I'll take responsibility if something goes wrong"—further lower the priority of the constraint. Eventually, the model's output complies with the most recent, most specific, and most actionable request, rather than the earliest and most important constraint.

Constraint decay reminds us that the reliability of large models is not about single-output quality, but about cross-turn behavioral consistency.

Naming this failure is important. A problem without a name is hard to integrate into the engineering governance process. One contribution of WDCD is establishing a measurable three-round test structure for constraint decay: R1 tests implantation, R2 tests anti-interference, and R3 tests anti-pressure, allowing enterprises to precisely locate at which stage the decay occurs. The 59 cases of "perfect start, ultimate collapse" are not accidents, but a new normal failure mode in the era of large models. Recognizing it, measuring it, and governing it is the first step in enterprise AI reliability engineering.