Quick Reference: Domain 5 — Configuration and Knowledge Management

A Project has two configurable halves doing different work. Custom instructions shape behaviour and apply to every chat in the Project. Project knowledge supplies material, consulted when the work calls for it. Instructions answer "how should this work be done"; knowledge answers "what should it be done from".

• The container test: for every piece of a setup, ask one question: is this a rule about behaviour, or material to consult? "Write for residents who are not housing professionals" is behaviour, so it goes in the instructions. The repairs policy is material, so it goes in the knowledge.
• Why the split matters: a knowledge file can be swapped in one step when the source document is revised; a policy pasted into the instructions has to be found and cut out by hand.
• The two wrong-container failures: reference material pasted into the instructions (the behavioural rules drown, and stale text gets trapped where it cannot be cleanly replaced), and the standing rule uploaded as a knowledge document (applied only when retrieval happens to surface it; sometimes is not a standard).
• Build from your manual habit: whatever you re-explain at the start of every conversation is the instruction set; whatever you re-attach is the knowledge base. Then run a real task with a short task-only prompt and see what you no longer had to say.

On the exam: the keyed answer routes behaviour to the instructions and material to the knowledge; distractors route at least one piece the other way, usually dressed as thoroughness. The stem begins after the Project decision, so "use a Project" is never the keyed answer here; that judgement is Domain 3's.

Material reaches a Project by two routes, and the tell in almost every stem is how the material changes, never how important it is.

• Governance: on Team and Enterprise plans, an Owner or Primary Owner must enable connectors for the organisation before members can use them. The professional move is a request to the workspace administrator, not improvisation.
• Permissions mirror the source: the connector reaches only what that user can already reach in the connected service, so two colleagues in the same Project can get different answers. That is a property of permission systems, not a fault in the Project. 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 (checked 1 September 2026 — on Team and Enterprise plans, owners can allow these actions to run without asking each time).
• Retrieval, not cover-to-cover reading: a large knowledge base is searched, with only the most relevant content loaded, as a project approaches its context limits. Two documented levers: clear, descriptive file names, and naming a specific document in your prompt.
• Curation beats completeness: every never-needed document dilutes the search space and is a chance to be quoted at the wrong moment. Choose the handful of documents the work needs, then route each by how it changes.

On the exam: 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, not this one.

System-level instructions in this certification are plain-English standing rules at three documented levels. There is no technical layer underneath.

• Precedence: where levels overlap, organisation instructions win; individual instructions still apply to anything the organisation rules do not address.
• The placement question: what is this rule true of? You everywhere: account-wide. One body of work: that Project. Everyone in the organisation: a request to the workspace Owner. Only today's job: today's prompt, which is the boundary with Domain 1.
• Behaviour, not aspiration: "keep each item under ninety seconds when read aloud" can be followed and failed; "be engaging" cannot. The test for every line: could a new colleague follow this and be checked against it?
• Short and prioritised beats long and exhaustive: when everything is a rule, the rules compete. Group and prioritise rather than appending. Styles control how a response is formatted and delivered. Our reading, not a documented rule: they are not a home for rules about substance.

On the exam: the aspiration dressed as an instruction is the signature distractor, and an ordinary member setting an organisation-wide rule personally is the signature level error. The keyed answer passes both tests; each distractor fails exactly one.

These are product details that move. They carry a date rather than being taught as durable rules, and this domain's practice questions never turn on them.

• RAG plan availability was contradictory in the Help Center itself. On 14 August 2026 one article said retrieval-augmented generation "is available for all Claude plans" and another said it "is only available to users with paid Claude plans". Current state (checked 30 September 2026): both now say paid plans (Pro, Max, Team and Enterprise). Plan availability still moves, so do not answer an exam question from it.
• Styles have left the personalisation article (checked 30 September 2026). Its formatting comparison now names Skills as the way to customise how Claude formats and delivers its responses. This domain's practice questions never turn on either feature.
• Organisation instructions cap at 3,000 characters. A limit, not a target — a set that long has usually stopped being a set of standing rules.
• Tier gating. Connectors need an Owner or Primary Owner to enable them on Team and Enterprise plans, and organisation instructions are set by Owners and Primary Owners (checked 1 September 2026). Both are load-bearing for the escalation answers in this objective.

Every item in this objective is the same Project: set up well once, and quietly drifted since. Three decay modes, all invisible from inside day-to-day use: knowledge goes stale (an upload is a snapshot and nothing announces the source was superseded), instructions outlive the world they describe, and scope creeps until the instructions fit none of the work.

• Remove, do not accumulate: when a document is superseded, remove the old version. A working Project needs exactly one answer to "which version is current"; a note file saying which governs, or an instruction telling Claude to prefer the newer document, patches around a problem the knowledge base should not have.
• Sweep after every swap: read the instructions for rules written against the old wording; a standing rule quoting the old notice period outlives the file it came from.
• Informing is a human step, always: the only documented notification is the email when a project is first shared, and no notification of any kind is documented for later edits to knowledge or instructions. Tell collaborators what changed and when; the date lets work in flight be placed as pre-revision.
• The habit that survives a busy calendar: a named owner, a review point tied to a real recurring event, and removal treated as an active step of the review.

On the exam: the keep-both-versions option feels thorough and careful, which is exactly why it is wrong. A stem that opens with a bad output and asks what went wrong belongs to Domain 7, and even a perfectly maintained Project produces first drafts whose facts get verified under Domain 2.