TL;DR
When you iteratively refine something with an LLM — text, a plan, a structure — the model zeroes in on the new request and quietly breaks whatever you set up earlier. You asked for "add more emotion" — and the length limit vanished. You asked for "make it stricter" — and the tone from turn two disappeared. This is called regression accumulation: regression that piles up conversation after conversation.
LLMs are built so that the latest request weighs more than the accumulated context. The model doesn't "remember" how important the old constraints are — it optimizes for the newest requirement, sacrificing the previous ones. Not because it forgot, but because it never sees a signal that the old rules are still mandatory.
Verification Gate is an explicit instruction before every edit: list all active requirements, apply the new one, check that all the old ones still hold. If there's a conflict, report it — don't quietly "fix" it. This flips the model from "just do the latest thing" mode into "do the new thing while preserving everything before it" mode.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
(All steps go in a single message. Repeat before every edit.)
STEP 0: List all active requirements → explicit list
STEP 1: Apply the requested change → draft
STEP 2: Check each requirement from the list → status: ✅ / ❌
STEP 3a: If everything's OK → output the final result
STEP 3b: If there's a conflict → name the specific conflict, propose
a compatible version or explicitly state that it can't be reconciled
Example in Action
Task: You're writing a price-increase letter to a client — iteratively, over several passes. You set early requirements: no more than 7 sentences, no apologies, business tone, keep the partnership vibe. After the 4th round of edits, the letter sprawled to 15 sentences, "we understand this is inconvenient" crept in, and the business tone vanished.
Prompt with Verification Gate (before every edit):
List of active text requirements:
1. No more than 7 sentences
2. No apologies or justifications
3. Business-like, direct tone
4. Keep a partnership tone, not a directive one
5. Justify through value, not through costs
New requirement: {new_requirement}
Current version of the text:
{current_text}
Instructions:
1. Apply the new requirement
2. Check: is every item in the list above satisfied? Give a status ✅/❌
3. If there's a ❌ — name the conflict explicitly and propose a version without it
4. If the conflict is unresolvable — say so, don't silently sacrifice
old requirements
5. Output the final text only if every item is ✅
Result: The model shows an explicit check against every item before the final text. If the new requirement conflicts with an old one (say, "add emotion" vs. "business tone") — that will be visible directly, instead of quietly showing up as a lost tone in the text.
Why It Works
LLM weakness: The model doesn't store "priorities" — it generates text based on the nearest context. The most recent message statistically outweighs something written 5-6 messages ago. Early constraints don't disappear from the history, but their weight in generation drops.
LLM strength: The model handles explicit lists and "match/mismatch" checks well, as long as the condition is stated directly. It's good at comparing — but only if you give it something to compare against.
How Verification Gate leverages this: We turn the implicit "remember everything" into an explicit checklist before every step. The model doesn't "remember" the importance of old requirements — it re-reads them. On top of that, we add an explicit exit condition: "only if everything is ✅." This removes silent trade-offs.
Control levers:
- Checklist granularity → more items = tighter control, but more tokens
- "Report the conflict" instruction → without it, the model will quietly compromise
- The phrase "don't silently sacrifice old requirements" → critical: without it, the model often tries to "satisfy both" by blurring both
- "Output the final text only if everything is ✅" → a hard exit condition; drop it if you want to see drafts even when there's a conflict
Prompt Template
List of active requirements:
{requirement_1}
{requirement_2}
{requirement_3}
[add as many as needed]
New requirement: {new_requirement}
Current version:
{current_content}
Workflow:
1. Apply {new_requirement} to the current version
2. Check each item in the list: status ✅ met / ❌ violated
3. If there's a ❌ — name the specific conflict and propose a version without it
4. If the conflict is unresolvable — say so explicitly, don't sacrifice
old requirements for the new one
5. Output the final result only if everything is ✅
Placeholders:
- {requirement_X} — specific constraints from earlier rounds: tone, length, structure, restrictions
- {new_requirement} — what you're asking to change right now
- {current_content} — the current version of the text/plan/structure
🚀 Quick Start — paste into the chat:
Here's a Verification Gate template — it helps avoid losing early
requirements during iterative edits. Adapt it to my task: {your_task}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what requirements are already set and what needs to change right now — because without that info it can't build the checklist and the verification loop.
Limitations
⚠️ First turn: You don't need this method on the very first message — regression only kicks in from the second one on. Start using it from the first edit.
⚠️ Subjective requirements: If constraints are fuzzy ("keep it feeling light"), the model might mark ✅ where you'd see a ❌. The more concretely you phrase requirements, the more precisely the method works.
⚠️ The method reduces regression, but doesn't eliminate it: Even with explicit verification, some conflicts remain. Strict control on complex tasks may require an explicit "roll back to the previous version and try a different approach."
⚠️ Token growth: Every round now includes a list of all requirements plus statuses. In long conversations, context grows faster. To save tokens, you can move the requirements list into the system prompt.
How It Was Studied
The idea was simple: build evolution tasks with explicit requirement accumulation — so that every next step depends on all the previous ones — and check not "did the last step get done correctly" but "did everything that came before survive."
The researchers took 542 programming tasks and built an 8-step chain of changes for each one: first a basic implementation, then error handling, input generalization, caching, a new feature, refactoring into a class, adding logging, and algorithm optimization. At every step, the model wasn't just supposed to fulfill the new requirement — it had to preserve everything before it. That's the key difference from typical benchmarks: the final version was checked against every test from step one, not just the most recent ones.
They tested six models — GPT-4o, DeepSeek-V3, Qwen2.5-Coder-32B, Qwen3-32B, DS-R1-Distill-32B, and Llama-3.1-8B — across 26,016 instances (542 tasks × 6 models × 8 steps). The result turned out to be surprisingly harsh: between 40% and 73% of tasks lost at least one previously working requirement by the end of the conversation. Every single model, no exceptions.
The most unexpected pattern: regression showed up strongest at the steps that added error handling and input type expansion — tasks that intuitively feel "isolated." In reality, they interact deeply with the preceding logic. The researchers also manually reviewed 384 failure cases and found that the main cause wasn't lost context, but conflicts between new instructions and old requirements. The model didn't "forget" — it just prioritized in a way that didn't favor you. Of all the strategies tested, only Verification Gate (checking new code against earlier tests + rolling back when needed) consistently improved every model: DeepSeek-V3's final quality jumped from 75.8% to 87.9%, and Llama-3.1-8B's went from 31.6% to 47.3%.
Adaptations and Extrapolations
1. Adaptation: Verification Gate for Non-Technical Tasks
The original was built for code, but the mechanism is universal. Any iterative chat work — documents, strategies, structures — suffers from the exact same problem.
💡 For multi-turn work with documents and strategies:
Add the requirements list to the system prompt or to the top of every new chat. This makes the requirements a "permanent part of the context" instead of messages that fade away.
[System prompt / start of chat]
We're working on {document_type}. Active, non-negotiable requirements:
1. {requirement_1}
2. {requirement_2}
...
For every change — first list the requirements, then make the change, then verify.
Conflict → report it explicitly, don't silently sacrifice old requirements.
2. Technique: "Requirements Snapshot" Every 3-4 Turns
🔧 Accumulated requirements → an explicit recap mid-conversation
Every 3-4 rounds of edits, ask the model to take a "snapshot" of the currently active requirements:
Before we continue, write out the full, up-to-date list of
requirements for {document} — everything we've established in this conversation.
Number them.
This list then gets plugged into the Verification Gate. It's useful in long sessions where requirements were added gradually and never got collected in one place.
3. Extrapolation: Verification Gate + Chain of Thought (CoT)
If you want to see why the model decided a requirement was met, add an explicit reasoning output before the final text:
After checking each requirement, explain in 1-2 words
why you marked it ✅ or ❌. Then output the final result.
This helps catch "false ✅s" — cases where the model decided a requirement was met, but you'd disagree.
Resources
Paper title: Regression Accumulation in Multi-Turn LLM Programming Conversations (ASE '26, 2026)
Authors: Yonghui (Andie) Huang, Lin Ma, Amjed Tahir, Qian Zhang, Liwen Xiao, Lysa Xiao
Organizations: Massey University (New Zealand), University of Otago (New Zealand), Alibaba Research Center for Complexity Sciences / Hangzhou Normal University (China)
Replication package: https://anonymous.4open.science/r/multi-turn-llm-regression-E73E
Benchmarks: HumanEval+, MBPP+ (EvalPlus)