TL;DR
ContextGuard is an editing technique that, before any edits, splits the text into four zones: what's definitely correct, what's definitely factually right, what might be missing, and what might be wrong. Only the zones of doubt get fixed — everything confirmed is explicitly locked against changes.
When you ask a model to "check and improve," it often breaks what was already working. For example: a response with 10 requirements — the model fixed the 3 that were violated but accidentally broke 2 of the 7 that worked. Net result: worse than before. This happens because "improve" reads as a signal to freely rewrite everything: the model generates text following an "improved version" pattern — which means any fragment is at risk of being replaced.
ContextGuard turns the vague task "make it better" into a precise one: here's list D — fix only that; here's list A+B — don't touch a single word. Three steps: a draft with a reminder of the key constraints → a structured audit into four categories → editing only the doubtful parts while explicitly protecting what's confirmed.
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
STEP 1 (separate request): Draft
Task + all requirements + at the end: a reminder of the 2-3 most important
→ Output: a draft response
STEP 2 (separate request): Structured audit
Split the previous response into 4 categories:
A: confirmed satisfied constraints
B: confirmed correct facts and data
C: possibly missed requirements
D: possibly incorrect parts
→ Output: a structured list across the four zones
STEP 3 (separate request): Protected edit
Fix only C + D
DO NOT TOUCH A + B — keep them verbatim
→ Output: the final response
Three separate requests. You can merge steps 2 and 3 into one, but an audit without a pause gives worse results.
Example in Action
The task: Write an Amazon product listing. The marketer's requirements: keywords, character limits, banned words, title structure, tone of voice, a mention of the promo, a CTA — 10+ criteria at once. A plain "check and improve" request neatly satisfies 7 out of 10 and innocently breaks 2 of the remaining 3.
Prompt (Step 1):
Write an Amazon product listing — BORT Pro 500 ml travel mug.
Requirements:
1. Title: [brand] + [name] + [capacity], 60 characters max
2. Keywords in the text: "travel mug," "stainless steel," "leak-proof"
3. Banned words: "best," "number 1," "unique"
4. Description: 800–1000 characters
5. Structure: benefit → specs → CTA
6. CTA: ask the shopper to add it to their wishlist
7. Mention the promo: 20% off through the end of the month
8. Tone: friendly, no corporate jargon
9. Don't mention competitors
10. First sentence — lead with the shopper's pain point
REMINDER BEFORE ANSWERING: make sure items 3, 4 and 6 are met —
they're the ones most often violated.
Prompt (Step 2):
Check your previous response. Split its content into 4 categories:
A (definitely satisfied — constraints): [what definitely meets the requirements]
B (definitely correct — facts and data): [what is definitely factually correct]
C (possibly missed or not addressed): [what might have been left out]
D (possibly wrong or violating requirements): [what is in doubt]
Prompt (Step 3):
Based on the audit, fix the listing:
— FIX: everything in categories C and D
— DO NOT TOUCH: everything in A and B — keep it verbatim, exactly as is
— Output the final version of the listing
The result: Step 2 gives you a structured list — which items are definitely met and which are questionable. Step 3 outputs a listing where the working fragments are preserved word for word and the problem spots are fixed surgically. The odds that the model "accidentally rewrites" something correct drop sharply.
Why It Works
The LLM weakness. An "improve" request carries no information about what's already good. The model generates an "improved version" following a pattern — which means rewording the whole text. Without explicit instructions on what's off-limits, the model can't tell "already correct" from "needs fixing." It isn't lazy or sloppy — it just follows the "make it better" signal the only way it knows how.
The LLM strength. Models follow specific constraints well. "Don't change the items on this list" — done. "Edit only what landed in category D" — done. The more specific the instruction, the more precise the execution.
How the method turns the strength against the weakness. ContextGuard shifts the uncertainty from the editing step to the audit: first the model explicitly decides what we know for sure and what's in doubt, and then it gets a precise task — fix only list D, preserve list A+B. The vague "improve" signal is replaced by a precise "here are the zones to work on."
Control knobs: - Audit granularity — ask for the breakdown at the sentence level rather than the paragraph level: more precise for short texts with dense requirements - The reminder in step 1 — the longer the original prompt, the more important it is to repeat the key constraints at the very end: context at the start of a long prompt loses weight by the time generation happens - An extra category E — add "E: definitely wrong" for tasks where the difference between "possibly" and "definitely" is critical (medicine, law, finance) - Specialized audit — split step 2 into several auditors: one looks only at formatting, another only at facts, a third only at rule compliance
Prompt Template
### STEP 1: Draft with a reminder
{task_and_context}
Requirements:
{numbered_list_of_requirements}
REMINDER BEFORE ANSWERING: make sure these are met:
{2-3_key_requirements_most_often_violated}
---
### STEP 2: Structured audit
Check the previous response. Split its content into 4 categories:
A (confirmed satisfied constraints):
— [what definitely meets the requirements]
B (confirmed correct facts and data):
— [what is definitely factually correct]
C (possibly missed or not addressed):
— [what might have been left out]
D (possibly wrong or violating requirements):
— [what is in doubt]
---
### STEP 3: Protected edit
Based on the audit, fix the response:
— FIX: everything in categories C and D
— DO NOT TOUCH: everything in A and B — keep it verbatim, exactly as is
— Output the final version
What to plug in:
- {task_and_context} — the task description, as usual
- {numbered_list_of_requirements} — all requirements, numbered; the more specific the better
- {2-3_key_requirements} — whatever most often gets "lost" in a long context
🚀 Quick start — paste into the chat:
Here is a ContextGuard template for protected editing.
Adapt it to my task: {your task}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what your requirements for the result are and what's critical not to break — because the list of requirements and the split into "protected zones" drive the whole logic of the method. It'll take the pattern from the template and plug in your details.
Limitations
⚠️ No list of requirements — no point. ContextGuard only works when there are concrete criteria the response must meet. If the task is open-ended ("write something beautiful"), there's nothing to audit.
⚠️ Three requests instead of one. For one-off tasks — no big deal. For a stream of similar tasks — the overhead is noticeable. The method pays off on tasks with 7+ explicit requirements.
⚠️ The audit itself can be wrong. If the model wrongly files a faulty item under category A (protected), the error gets locked into the final version. For critical tasks, review the step 2 output before running step 3.
⚠️ On easy tasks the difference from ordinary editing is minimal. The study showed the method is especially useful on long contexts with dense requirements. On simple, short tasks a standard "check this" request gives comparable results.
How It Was Studied
The researchers used CL-Bench — a benchmark built specifically to test how well models apply complex rules from context. The condition is strict: a task counts as solved only if all criteria are met — on average 16.6 criteria per task, up to 114. One mistake in a minor formatting rule and the whole task fails, even if the core logic is right.
They compared three approaches: the baseline response with no editing, standard Self-Refine ("check and improve"), and ContextGuard. On Qwen3.5-4B: baseline — 9.64% of tasks solved, Self-Refine — 10.48%, ContextGuard — 13.85%. A particularly telling moment: in the "Empirical Discovery" category, Self-Refine scored −0.5% relative to the baseline — meaning unprotected editing was actively breaking what worked. ContextGuard in the same category gave +4%.
To find out what exactly does the work, they removed components one at a time. The biggest contribution comes from the structured audit. Next is the protection block (A+B): remove it, keep only the "list to fix," and the result drops. That directly confirmed the hypothesis: knowing what to fix isn't enough — you also have to explicitly protect what's right. The reminder in step 1 and specialized task-type "checkers" added further, smaller gains.
Adaptations and Extrapolations
🔧 Technique: specialized role-based auditors → better at catching their own class of errors
The study shows that different task types produce different classes of errors — formatting, procedural, factual, stylistic. You can simulate this in a single step:
Check the response as three independent auditors:
Auditor 1 (Format): looks only at structure, character limits,
banned words — outputs their own C and D
Auditor 2 (Facts): looks only at the accuracy of data and numbers — outputs their own C and D
Auditor 3 (Requirements): looks only at compliance with the stated rules —
outputs their own C and D
Total: a combined C and D list from all three
It's a rough approximation of the method, but it mimics the logic of the "category-conditioned signals" from the original — different "experts" catch different classes of errors.
🔧 Extrapolation: the protection principle without a formal audit — the manual version
If you can see for yourself what's good in the response and what isn't, you can set the Protection Set by hand without running an audit:
Items 1, 3 and 5 from your response — keep them verbatim,
I accept them.
Items 2, 4 and 6 — redo them: [specific complaints].
Output a corrected version where the accepted items
are copied without changes.
This is the manual version of protected editing — it works without the three-step protocol and is enough for most everyday situations.
Resources
ContextGuard: Structured Self-Auditing for Context Learning in Language Models
Authors: Hongbo Jin, Chi Wang, Haoran Tang, Zhongjing Du, Xu Jiang, Jingqi Tian, Qiaoman Zhang, Jiayu Ding
Institutions: Peking University, SCUT (South China University of Technology), Tsinghua University
Related benchmark: CL-Bench (Dou et al., 2026)