TL;DR
The more rules, tags and shorthand codes you pile into a system prompt, the worse the LLM understands your actual task. This isn't a bug in one particular model — it's a structural property of transformers (the architecture behind GPT, Claude and the rest). The authors call this effect "Index Sickness": the model stops grasping what the task actually means and starts "playing with symbols" — producing answers that look perfectly logical inside your notation system but have come unmoored from reality.
The key insight: an LLM gets stuck in your tag system not because it has a "bad memory." The real reason is that the attention mechanism gives high "weight" to anything that shows up often in the context — whether or not it's still relevant. Writing "ignore the old scheme" won't work. The model sees the old terms, and they shape the answer. Physically removing them is the only reliable fix.
That leads to the Pan Principle: "natural language with an explicitly stated purpose carries more information than any symbol system." In practice it boils down to simple mechanics: every time you start a new session, state the goal clearly, keep the project's "current state" in a separate clean document, and keep the history somewhere else.
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: Every message starts with the GOAL
→ 1-2 sentences: what needs to happen right now and why
STEP 2: Context — ONLY the current state
→ Baseline document: contains only Purpose + Method + Resources
Rewritten in full after every task
Does NOT contain discussion history or rejected options
STEP 3: History — kept separate from the baseline
→ Session log: why decisions were made, what was dropped, and why
Used only for audits and backtracking, not for active work
Both steps are done by hand in the chat — no code or infrastructure needed.
Example in Action
The task: You run a Substack newsletter about venture capital and have spent a month working with Claude on your content strategy. Along the way you've built up a giant system prompt full of rules: "Type-A posts are...", "The #opinion column is marked with tag M1", "Don't confuse it with the 'teardown' format", "Rule 7: never use the word 'unique'" — 40 lines of this. You notice Claude getting confused more and more often, breaking its own rules and giving weird advice.
The prompt — new approach (instead of 40 lines of rules):
GOAL OF THIS SESSION: Write three posts for next week. I want to
show my readers how LPs (the people who put money into funds) think —
what questions they ask founders and why most pitches
fall apart in the first 10 minutes.
CURRENT STATE OF THE NEWSLETTER:
- Audience: pre-seed/seed startup founders, 12K subscribers
- Voice: no corporate speak, insider perspective, concrete examples
- Core value for the reader: understanding how people "on the other side of the table" think
- Post format: 800-1,200 characters, one thesis, one story, one takeaway
Suggest topics for three posts that serve this goal.
Result: Claude will focus squarely on the stated goal — "how LPs think." It won't be busy trying "not to break rule M1" or remembering how "Type-A" differs from a "teardown." It will offer three concrete angles: probably the typical questions LPs ask, red flags in pitches, and what founders don't know about due diligence. The answer will be shorter and sharper than with 40 lines of rules.
Why It Works
An LLM doesn't "read" the context top to bottom like a person does. The attention mechanism distributes "weight" across every word in the context at once. The more often a term appears, the more influence it has on generation. That means your outdated rules and old document versions literally drag the answer back into the past — even if you wrote "ignore this."
There's one thing LLMs are great at: activating the right knowledge from their weights once they understand the WHY. The model was trained on huge amounts of text — it already knows everything about newsletters, venture capital and LPs. You don't need to explain every term through symbols. Explain the goal, and it will pull up what it needs on its own.
The Pan Principle exploits this directly: an explicit goal is a signal that narrows the model's "interpretation space" down to the task at hand. Instead of trying to hand the AI a detailed instruction manual (supply side), we switch on the right mode through the goal (consumer side).
Control levers:
| What to change | Effect |
|---|---|
| How specific the goal statement is | Sharper focus → fewer "hallucinations" off to the side |
| Length of the baseline document | Longer → higher risk of semantic drift |
| History present in the active context | History in context = old concepts shape the answer |
| Tag words vs. descriptive language | Tags → cognitive load; description → direct activation |
Prompt Template
GOAL OF THIS SESSION: {exactly what needs to be done right now} so that
{why — what result we need in the end}.
CURRENT STATE OF {project/task name}:
- Context: {who the audience is / what the project is / key parameters}
- Method: {how we usually do this — 1-2 sentences}
- Resources: {what we have right now — materials, data, constraints}
{The specific request for this session}
What to fill in:
- {goal} — a concrete action, not an abstraction ("write three posts," not "working on content")
- {why} — for whom and to what effect ("so readers understand how LPs reason")
- {current state} — rewrite it IN FULL after every major session; don't keep appending to it
- Discussion history and "we tried X but dropped it" — keep that out of the baseline
🚀 Quick start — paste into the chat:
I want to get better results working with you on a long-term project.
Help me apply the Pan Principle and Baseline-Log Separation
from this research. My project: {describe your project}.
Ask me questions so we can put together my first baseline document.
[paste the template above]
The LLM will ask about the project goal, the audience, your typical tasks and how your system prompt is currently set up — because a baseline requires understanding the "minimum sufficient context" for your specific task. It will take the template structure and assemble your first clean baseline for you.
Limitations
⚠️ Maintenance discipline: This only works if you actually rewrite the baseline after every big task instead of tacking things on. Most people will keep appending — and a month later they'll have the same bloated context.
⚠️ Short-term tasks: If you use an LLM for one-offs or short tasks, Index Sickness simply doesn't have time to develop. These principles pay off most when you're doing "dozens of sessions on one project."
⚠️ Single-context models: In a standard ChatGPT/Claude chat, every new conversation starts from scratch — context "contamination" matters inside one long conversation or when you work with Custom Instructions / Projects. If you work in Projects or carry context over by hand, this is critical.
⚠️ "Telling it to ignore": Writing "ignore the previous scheme" or "these tags are obsolete" in a prompt is mechanically unreliable. Transformer attention can't lower a weight just because you declared it should. Physically removing the text from the context is the only method that works.
How They Studied It
The authors ran action research — a study where the researcher is also a participant. Over one month, one person (the Owner) built a real WeChat mini-app (Bangv3) across 391 sessions with two AI roles: Chief-of-Staff and Developer. The Owner didn't write a single line of code by hand — only discussed tasks with the AI. The result: ~80,000 lines of code in 506 files.
The turning point came at session 215: the AI produced a detailed "legislative act" for the system — logically flawless inside the symbol system, but a grep check revealed that the corresponding files physically didn't exist. The AI had built a complete "finished state" in the symbolic layer while being totally disconnected from reality. By then the system prompt had ballooned to 308 lines of defensive rules and patches added after every incident.
An interesting detail: after switching to Baseline-Log Separation and the "goal + natural language" principle, the AI Instructions shrank by ~75%. And over the next ~150 sessions, the symptoms of Index Sickness never came back once. It's not a controlled experiment — but 150 sessions without a relapse after completely rethinking the approach says a lot.
The authors also cite outside evidence: Chroma tested 18 LLMs and showed that irrelevant material in the context causes nonlinear performance degradation even with perfect recall. Another group (Raju et al.) recorded a sharp drop in agent success rates when the context was forcibly expanded — even when all the needed data was inside. Both results point the same way: the problem isn't "what you feed in" but "how the AI activates information."
Original from the Paper
The Pan Principle formula:
Natural language + Purpose = Maximum information quality
Natural language - Purpose = Ambiguity noise
Baseline structure (the three elements a baseline must contain):
Purpose + Method + Resources
Baseline (e.g., context.md):
- Overwrite-mode updates
- Stores only current task triple: Purpose + Method + Resources
- Purpose comes first — AI first understands purpose, then selects
methods based on its own knowledge, then organizes just-sufficient resources
- After each task, baseline is overwritten with current truth only
- Carries NO trace of historical discussion
Session Log:
- Append-mode
- Contains decision process: options considered, why some were eliminated
- Used for audit and backtracking only
- NOT loaded into active context during task execution
Context: This is a working spec from the real Bang-v3 project. According to the authors, the "Purpose + Method + Resources" structure is the minimum sufficient context for one working session.
Adaptations and Extrapolations
💡 Adaptation for writing a book / long-form text
A typical situation: you're writing a nonfiction book with Claude. You've racked up 20 sessions, and the System Prompt has 50 lines about chapter structure, style, terminology, "don't call it chapter X, it's now section Y." Claude periodically gets tangled up in the terminology.
GOAL OF THIS SESSION: Draft section 3.2, "How a reader decides
whether to trust an author." I want to give the reader a concrete
tool — a 4-item checklist — with no theory.
CURRENT STATE OF THE BOOK:
- Audience: entrepreneurs aged 30-45 who read on the go
- Voice: conversational, not academic, examples from small-business life
- Where we are: Part 3, "Trust"; the previous section, 3.1, ended
with the thesis "trust is built on predictability." This section is the logical follow-up.
- Length: 800-1,000 words
Write the draft.
🔧 Technique: "Goal on the first line" — an instant hack
If you don't feel like rebuilding your whole workflow, just add one line to the start of every message:
GOAL: {one sentence — what you need and why}
{the rest of your request as usual}
This is the bare-minimum version of the Pan Principle. It won't fix a polluted context, but it noticeably sharpens the focus of the answer — especially in long conversations where Claude is already "drifting" in the context of earlier discussions.
🔧 Technique: Diagnosing Index Sickness in your own setup
If you want to check whether your current AI project has caught the bug:
Look at our system prompt / context. Find:
1. All symbolic labels (tags, codes, numbering like "Type-A", "M1")
2. Rules phrased as "don't do X" or "remember that Y is obsolete"
3. Patches — rules added after a specific incident
For each item, answer: could it be replaced
with one plain-language sentence that states the GOAL?
If every symbol can be replaced with a natural explanation, the symbol is dead weight. The warning sign: when explaining your symbol system takes more space than the task itself.
Resources
Paper: Written by AI, Managed by AI: Semantic Space Control and Index Sickness Elimination Across 391 Consecutive Sessions
Authors: Hui Zhang (张慧), Shenzhen Yunxi Technology Co., Ltd. · Shuren Song (宋树仁), Information Technology Center, Tsinghua University
Date: June 17, 2026 · arXiv · cs.SE / cs.HC / cs.CL · License CC BY 4.0
Bang-v3 project repository and CSF framework: https://github.com/huidev2025/CSF
Case documentation: https://huidev2025.github.io/CSF/cases/bang-v3/README_en.html
Key references from the paper: - [6] Chroma: systematic tests across 18 LLMs — distractor degradation - [7] Raju et al. — agent success rate drop under extended context - [8] Liu et al. — "Lost-in-the-Middle" phenomenon in long contexts