Project Knowledge: What to Upload, When to Split
Not every document belongs in Project knowledge — matching a source's update frequency to the right mechanism is the whole scoping decision.
The instinct, once you understand what Project knowledge does, is to upload everything. Every document even loosely related to the work goes in, on the theory that more context can only help. It's the wrong instinct, and it fails in a specific, predictable way: not by making Claude confused, but by making it confidently wrong.
The Scoping Question Nobody Asks
Project knowledge is a snapshot. Whatever you upload gets indexed at the moment you upload it, and it stays exactly that way until you manually re-upload a newer version. That's not a limitation to work around — it's the entire design, and the entire question you have to answer before you upload anything: is this source stable enough that a snapshot of it stays true?
Reference material — a style guide, a glossary, an archive of past work — passes that test easily. It rarely changes, and when it does, you're usually the one changing it, so you remember to re-upload. A live dashboard, this week's inventory count, or anything with a number that moves on its own fails the test badly. Upload it once and you've created a source that looks authoritative — it's sitting right there in Project knowledge, cited with confidence — while quietly drifting further from true every day nobody re-uploads it.
The middle case is the one people get wrong most often: a document you're actively drafting right now. It feels like it belongs in the knowledge base because it's central to the work. But it changes every few minutes while you're working on it, which makes it a terrible fit for a mechanism built around stability. Paste it into the chat instead. When it's finished and stable, then it graduates to Project knowledge as a completed reference.
Three Mechanisms, Not One
The upload button isn't the only tool you have, and treating it as the default for every source is what causes the scope creep. There are three real mechanisms, and each one fits a different freshness profile:
Upload to Project knowledge for anything static enough that a snapshot stays accurate — the reference material a new collaborator would read on day one.
Paste into the chat for anything you're actively working on right now, or anything you only need once. It's more friction per-use, but that friction is exactly correct for content that shouldn't be trusted as a standing reference.
Connect a live source for anything that changes on its own and needs to stay current — we cover connectors properly later in this track, but the short version is: if the source updates without you touching it, a snapshot upload is the wrong tool no matter how convenient it feels in the moment.
Getting this right isn't about picking the "best" mechanism — it's about matching the mechanism to how the source actually behaves. A knowledge base built entirely from stable, well-scoped uploads produces sharper, more trustworthy answers than one padded with stale snapshots of things that should have been pasted or connected instead.
When One Project Becomes Two
Even with good scoping discipline, a Project that's been useful for months can slowly drift into serving two different jobs at once. The failure mode isn't dramatic — it's incremental. You add one more document because it's "related enough." You add one more instruction with a conditional clause. None of it looks like a problem in the moment.
The pattern across all four questions is the same: you're not asking "is this Project too big" — size alone is a weak signal. You're asking whether the knowledge or instructions have started contradicting themselves depending on which task you're doing. That's the real cost of an unscoped Project — not clutter, but conflicting signal that makes retrieval fuzzier and instructions ambiguous exactly when you need them to be sharp.
A Habit Worth Building
The scoping decision is cheap to get right in the moment and expensive to fix later, because by the time a Project's knowledge base has drifted, you're not just cleaning up files — you're untangling instructions that have quietly started contradicting each other. The good news is that the fix is a habit, not a project: every time you're about to upload something, spend five seconds on the one-word question — static, or moving? — before it goes in.
That single habit, repeated over months, is most of the difference between a Project that gets sharper the longer you use it and one that slowly turns into a junk drawer with your name on it.