Custom Instructions (Project)
The behavioural half of a Project's configuration. These are standing rules that are written and saved in the Project screen. They 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. It is the documents, text and files uploaded to the Project's knowledge base. Claude uses them as context in every chat within the Project. When the knowledge approaches the context window limit, Claude switches to RAG mode and searches it instead (see Project Retrieval).
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 questions in objective 5.1 are the container test presented as a scenario. The right answer puts every piece in its right container; each wrong option puts at least one piece in the other container, usually presented as thoroughness or tidiness.
See also: 5.1 Configuring Projects with Instructions and Knowledge Sources
Wrong-Container Failures
The two ways a Project setup puts its pieces in the wrong container. The first is reference material pasted into the custom instructions. There it hides the behavioural rules, and stale text stays where it cannot be cleanly replaced. The second is a standing rule uploaded as a knowledge document. There Claude uses it as context, and nothing tells Claude to apply it to every reply. In a large Project, the search may not load it at all.
Exam context: Both failures make effective wrong options. The pasted policy is presented as "so Claude can never miss it"; the rule placed in the knowledge base fails because knowledge is context, not directions for every response.
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 tells you 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 schedule looks exactly as current in six months as it did on the day of upload.
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. This includes a colleague's half-finished edit.
Exam context: Route by how the material changes, never by how important it is. Some connectors can also take actions in connected services. The Gmail connector can send, reply to and forward email from your own account. By default Claude asks for your approval before each of these actions. On Team and Enterprise plans, an Owner can limit which actions a connector can take for everyone, and members cannot override it.
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 who ask about the same folder in their own chats can get different answers.
Exam context: Different answers for different users come from the permission system, not a fault in Claude. On Team and Enterprise plans, an Owner or Primary Owner must enable connectors before members can use them at all, and the Google Drive route adds documents only to private Projects (checked 13 November 2026).
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. This behaviour, called RAG (retrieval-augmented generation), activates as the project approaches or exceeds its context window limit. Below that limit, Claude uses the whole knowledge base as context.
Exam context: Two documented steps 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 adds unneeded material to the search space and is a chance to be quoted at the wrong moment.
Exam context: Adding the whole drive looks careful 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" box in the claude.ai settings, called "Instructions for Claude" in the older Settings layout. Anything written there applies to all of your conversations; the suggested content is personal and applies across all your work, 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 moved to account level change everything else you do, without any warning.
See also: 5.3 Creating Effective System-Level Instructions
Skill
A set of instructions that tells Claude how to do one kind of task, for example its steps, format and tone. A Skill is available in any chat, inside or outside a Project. Claude loads it when a request refers to the Skill's name or description. Skills now do the job of the deprecated Styles menu.
Exam context: Account-wide and Project instructions apply to every chat in their scope. So the steps for one kind of task do not belong there when that scope also holds other work, or when the task is needed outside it. A Skill holds them instead.
See also: 7.3 Optimising Workflows for Efficiency and Effectiveness
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 right answer 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 client email under 150 words" passes; "be engaging" does not.
Exam context: An aspiration written as an instruction is the typical wrong option in objective 5.3, 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 problem in which standing instructions collect 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 out of date because each upload is a copy from one moment. Instructions stay in force after the situation they describe has changed. The scope grows as related work is added. All three look fine from inside the Project.
Exam context: Because nothing signals drift, maintenance has to be scheduled. A question that opens with a bad output and asks what went wrong belongs to Domain 7, not to this objective.
See also: 5.4 Informing, Maintaining, and Updating Configurations
Superseded Version
The old copy of a revised document. The rule that seems wrong to a careful person: 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, check the instructions for rules written for 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 right answer. The date matters as much as the change, because it lets work in progress 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 makes the review happen; 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