Answer
What should not be put into an AI project's permanent context?
Anything discoverable, anything with a date on it, anything secret, and anything added because of one incident that never recurred.
Four categories: facts the system could establish by looking, anything with a date attached, credentials of any kind, and rules added after one incident that has not recurred. Each degrades the file while continuing to be believed.
Standing context documents fail by accumulation rather than by error. Nobody adds something wrong; people add things that were right, and the file grows until the parts that matter are competing with parts that do not. Knowing what to keep out is therefore more useful than knowing what to put in, and four categories account for most of the damage.
The first is anything discoverable. A description of the folder structure, a list of what a system contains, an account of how a process currently works. All of these duplicate something inspectable, all of them drift the moment the underlying thing changes, and none of them announces that it has drifted. The system then has two sources — the description and the reality — and it will sometimes prefer the one that is wrong, because it was stated authoritatively.
The second is anything dated: current status, what is in progress, what was decided last week, what the next step is. This content has a legitimate home and it is not here, because the two kinds have opposite lifespans. Durable constraints should stay true for months; status is wrong within days. Mixing them means a reader cannot tell which half of the file to trust, and the usual resolution is to trust neither.
The third is credentials, keys, tokens and anything else secret. This should be obvious and it is worth stating because the failure is so easy: a standing file is supplied at the start of every session, so anything in it is transmitted every time, and a credential in a project document is a credential in every request. There is also no reason for it to be there, since the system needs the capability rather than the secret.
The fourth is the least obvious and the most common: rules added in response to a single incident. Something went wrong once, a line was added, and the line stays forever regardless of whether the situation recurs. Individually each is harmless. Collectively they are most of what makes these documents long, and length is what degrades adherence to the rules that are actually load-bearing. A rule that has not been needed in a month is a candidate for removal, and removing it is maintenance rather than negligence.
There is a fifth thing worth excluding that is more of a judgement: general advice. Be careful. Think about edge cases. Consider the user. None of these is checkable, none changes what a system does, and each one consumes a share of the attention available to the instructions that would. If you cannot say what the output would look like differently, the line is not doing work.
The rules that stop being true are the ones nobody removes, because removing a rule feels like a risk and leaving it feels like nothing at all.
Siddharth Sharma, Context Theory
Related questions
Where should the excluded content go instead?
Status and progress belong in a separate working file with a clear name, so its staleness is expected rather than misleading. Discoverable facts belong nowhere, because the system can look. Secrets belong in the credential mechanism the tools already use. Single-incident rules belong in the check that would have caught the incident, which is a stronger fix than a line in a document.
How do you decide what to remove from an existing long file?
Go line by line and ask what the output would look like if the line were absent. Anything you cannot answer for is a candidate. This is faster than it sounds and usually removes a third of the document, and the improvement in adherence to what remains is noticeable immediately rather than gradually.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Visibility lift in AI-generated answers from GEO methods | up to 40% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Aggarwal et al., "GEO: Generative Engine Optimization", Princeton / Georgia Tech / IIT Delhi / Allen Institute for AI — KDD 2024 · GEO-bench · 10,000 queries across 8 domains · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A described structure or process in a standing file duplicates an inspectable reality and drifts silently when the underlying thing changes, creating two sources where the authoritative-sounding one is sometimes preferred over the correct one. | Comparing each descriptive statement in an existing instructions file against the current state of what it describes. |
| Constraint | A standing project file is supplied at the start of every session, so any credential it contains is transmitted on every request, and the system requires the capability rather than the secret in any case. | Checking whether the project instructions file is included in the initial payload of each session. |
| Response | Rules added in response to single incidents accumulate without review and constitute most of the length in mature instruction files, and length is what degrades adherence to the load-bearing rules, so an unneeded rule imposes a cost on the ones that matter. | Dating each rule in an instructions file and identifying which have been relevant in the last month. |
| Software | General advice that cannot be tied to an observable difference in output consumes attention without changing behaviour, so the removal test is whether the absence of the line would be visible in the result. | Asking, for each line, what the output would look like differently if it were removed. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one