Custom Instructions (Project)
The behavioural half of a Project's configuration: standing rules, written and saved in the Project screen, that tailor Claude's responses in every chat within that Project. The Help Center's own examples: instructing Claude to use a more formal tone, or to answer from the perspective of a specific role.
Exam context: Instructions answer "how should this work be done". A rule the work depends on every time belongs here, stated as a behaviour, not uploaded as a document.
See also: 5.1 Configuring Projects with Instructions and Knowledge Sources
Project Knowledge
The material half of a Project's configuration: documents, text and files uploaded to the Project's knowledge base, which Claude draws on to understand the context and background of chats within the Project.
Exam context: Knowledge answers "what should the work be done from". Its defining property is swappability: when a source document is revised, the file is replaced in one step, which pasted text cannot be.
See also: 5.1 Configuring Projects with Instructions and Knowledge Sources
Container Test
The one-question sorting rule for Project setup: is this piece a rule about behaviour, or material to consult? Behaviour goes in the custom instructions; material goes in the project knowledge.
Exam context: Most items in objective 5.1 are the container test in scenario clothing. The keyed answer routes every piece to its right container; each distractor routes at least one piece the other way, usually dressed as thoroughness or tidiness.
See also: 5.1 Configuring Projects with Instructions and Knowledge Sources
Wrong-Container Failures
The two ways a Project setup misroutes its pieces: reference material pasted into the custom instructions, where it drowns the behavioural rules and traps stale text, and a standing rule uploaded as a knowledge document, where it is applied only when retrieval happens to surface it.
Exam context: Both failures make reliable distractors. The pasted policy is dressed as "so Claude can never miss it"; the buried rule fails because sometimes is not a standard.
See also: 5.1 Configuring Projects with Instructions and Knowledge Sources
Uploaded Snapshot
What an uploaded knowledge file actually is: a copy taken on the day of upload. It is stable, predictable and identical for every user of the Project, and nothing announces when the source document is superseded.
Exam context: The right route for material that barely changes, and the predictable failure for material that does: the uploaded rota looks exactly as current in six months as it did on day one.
See also: 5.2 Managing Uploaded Knowledge and Connectors
Connector
The live route into a Project's knowledge: Claude reaches the connected source when you ask a question that needs it, retrieving the minimum information required. Google Docs added this way sync directly from Drive, so the work always uses the latest version, including a colleague's half-finished edit.
Exam context: Route by how the material changes, never by how important it is. Connectors can also take actions in connected services; the Gmail connector can send, reply to and forward email from your own account, and by default Claude asks for your approval before each of these actions.
See also: 5.2 Managing Uploaded Knowledge and Connectors
Permission Mirroring
The rule that a connector reaches only what each user can already reach in the connected service. Access in Claude mirrors access in the source system, so two colleagues using the same Project can get different answers from the same connector.
Exam context: Different answers for different users is a property of permission systems, not a fault in the Project. On Team and Enterprise plans, an Owner or Primary Owner must enable connectors before members can use them at all.
See also: 5.2 Managing Uploaded Knowledge and Connectors
Project Retrieval
How a Project with a substantial knowledge base is actually read: Claude searches the project knowledge and loads only the most relevant content, behaviour that activates as the project approaches or exceeds its context limits.
Exam context: Two documented levers improve what retrieval finds: clear, descriptive file names, and naming a specific document in your prompt to focus the search on it.
See also: 5.2 Managing Uploaded Knowledge and Connectors
Curation
The discipline of keeping a Project's knowledge to the small set of documents the work actually needs, rather than everything available. Every document that is never needed dilutes the search space and is a chance to be quoted at the wrong moment.
Exam context: The whole-drive dump reads as diligence and is always wrong. Whether a document is permitted in the Project at all, on privacy or policy grounds, is Domain 6's question.
See also: 5.2 Managing Uploaded Knowledge and Connectors
Account-Wide Instructions
The "Instructions for Claude" box in the claude.ai settings. Anything written there applies to all of your conversations; the suggested content is personal and cross-cutting, such as preferred approaches, common terms and general communication preferences.
Exam context: The placement test is strict: a rule belongs here only if it would improve your most unrelated conversation. One Project's rules promoted to account level quietly reshape everything else you do.
See also: 5.3 Creating Effective System-Level Instructions
Organisation Instructions
Standing rules that Claude follows in every conversation across an organisation, set by Owners and Primary Owners on Team and Enterprise plans. Where levels overlap, organisation instructions take precedence, and individual instructions still apply to anything they do not address.
Exam context: An ordinary member does not set these. The keyed move for a rule that should bind the whole organisation is a request to the workspace administrator, never a personal setting.
See also: 5.3 Creating Effective System-Level Instructions
New-Colleague Test
The checkability test for every instruction line: could a new colleague follow this and produce what you wanted, and could their output be checked against it? "Keep each item under ninety seconds when read aloud" passes; "be engaging" does not.
Exam context: The aspiration dressed as an instruction is objective 5.3's signature distractor, because "tell it to be clear and professional" always reads as sensible advice. It cannot be followed differently from the default, so it changes nothing.
See also: 5.3 Creating Effective System-Level Instructions
Per-Task Creep
The decay pattern in which standing instructions accumulate rules that were only ever true of one job. Because instructions apply to every chat in their scope, a one-job rule distorts every other job until someone remembers to remove it.
Exam context: Anything mentioning a date, a campaign or a current event is almost certainly per-task and belongs in that job's prompt, which is the boundary with Domain 1. The related length rule: a short prioritised set is followed more reliably than a long exhaustive one.
See also: 5.3 Creating Effective System-Level Instructions
Configuration Drift
The slow decay of a Project that was set up well: knowledge goes stale because uploads are snapshots, instructions outlive the world they describe, and scope creeps as neighbouring work accumulates. All three look fine from inside the Project.
Exam context: Because no trigger announces drift, maintenance has to be scheduled. A stem that opens with a bad output and asks what went wrong has left this objective for Domain 7.
See also: 5.4 Informing, Maintaining, and Updating Configurations
Superseded Version
The old copy of a revised document. The rule that runs against careful instincts: remove it when the new version arrives, rather than keeping both, because a working Project needs exactly one answer to which version is current.
Exam context: The keep-both option, with or without a note saying which governs, feels thorough and is wrong; so is an instruction telling Claude to prefer the newer document. After the swap, sweep the instructions for rules written against the old wording.
See also: 5.4 Informing, Maintaining, and Updating Configurations
The Inform Step
Telling the people who share a Project what changed in its configuration, and when. The only documented notification is the email members receive when a project is first shared with them; no notification of any kind is documented for later edits to knowledge or instructions.
Exam context: Informing collaborators is always a human action in the keyed answer. The date matters as much as the change, because it lets work in flight be recognised as pre-revision instead of argued about.
See also: 5.4 Informing, Maintaining, and Updating Configurations
Review Trigger
A review point tied to a real recurring event, such as the quarterly figures or the start of the season, owned by a named person. A diary note attached to something that already happens fires; a general intention to keep things current does not.
Exam context: The maintenance habit the exam rewards has three parts: a named owner, a real trigger, and removal treated as an active step of the review, because additions happen naturally all year and deletions never do.
See also: 5.4 Informing, Maintaining, and Updating Configurations