Lab 5 · Domain 5 · 12%

Configuration & Knowledge Management

This is the most hands-on lab in the track. So far you've prompted well, checked the output, chosen the right product, and fit Claude into a workflow. Now you'll stop re-explaining yourself every morning and build a Claude Project, a reusable workspace that carries your standing instructions and the documents Claude should reason from. By the end you'll have created one for your actual job, written instructions that hold up, curated its knowledge, and proven it will refuse a question it can't answer instead of inventing one.

Exam objectives covered

Configure Claude Projects with instructions and knowledge sources
Manage uploaded knowledge and connectors (e.g., Google Drive, Gmail)
Create effective system-level instructions
Inform, maintain, and update Claude configurations, knowledge sources, and instructions

What you need: a Claude account (claude.ai) on a plan that includes Projects, about 45 minutes, and one or two real documents from your work you're allowed to upload. No installation, no code.

1. What a Project Is, and When It Earns Its Keep

A plain chat starts from nothing every time. You paste the same background, restate the same rules, re-upload the same reference doc, and Claude does good work. Then you close the tab and all of that context evaporates. Tomorrow you do it again.

A Project fixes exactly that. It bundles two things that persist across every conversation you start inside it:

Custom instructions — standing guidance about who Claude is working as, for whom, and how the output should look. Written once, applied to every chat in the Project.
Knowledge sources — documents you upload, or connectors you attach, that Claude can draw on without you pasting them each time.

The judgment call is the same one you made in Lab 3 when you chose between products: match the tool to the shape of the work. A chat is right for a one-off, a task you'll do once and never repeat. A Project earns its keep when you do the same kind of work repeatedly: the weekly board update, contract reviews against your standard playbook, support replies in your company's voice. If you've re-explained the same context to Claude three times, that context belongs in a Project.

The test is repetition of kind, not topic. Every contract is different; the way you want them reviewed is identical. That identical part (the role, the standards, the output shape) is what a Project holds constant so you only ever supply what actually changes.

Try it in Claude

In claude.ai, find Projects in the left sidebar and create a new one. Name it for the recurring job it will serve, e.g. "Weekly Revenue Review" or "Vendor Contract Screen," not "Test."
Give it a one-line description of what work happens here. This is for you and your teammates, not for Claude; it's how anyone opening the Project knows what it's for.
Leave the instructions and knowledge empty for now. Start one chat inside it and ask a normal question. Notice it behaves exactly like a plain chat: an empty Project is just a folder. The value is entirely in what you put in it next.

2. Writing Effective System-Level Instructions

This is the core skill of the whole lab, and the one the exam leans on hardest. A Project's custom instructions are system-level: they sit above every conversation and shape all of them. Get them right and every chat starts smart. Get them vague and you've built a folder that reminds Claude to be nice.

Strong instructions do four things:

State the role, the audience, and the standing output conventions. Who is Claude acting as, who reads the result, and what does the output always look like? "You are drafting for a non-technical executive audience; default to plain language and a three-bullet summary at the top" removes a decision from every future chat.
Encode the criteria you'd otherwise retype. Remember from Lab 1 that criteria (the standard for a good answer) produced the biggest jump in quality. Instructions are where recurring criteria live permanently. "Rank findings by revenue impact" or "flag any clause that deviates from our standard terms" belongs here, not in every prompt.
Include the failure instruction. The single highest-leverage line from Lab 1 graduates into policy here: tell Claude what to do when the knowledge doesn't cover the question: say so plainly, don't guess. Without this, a Project confidently answers from general knowledge and you can't tell it apart from an answer grounded in your documents.
Describe how to work, not a single task. Instructions govern every conversation, so they must be about method, not about today's job. "Summarize the Q3 deck" is a prompt. "When I share a deck, extract the three decisions it asks the reader to make before summarizing anything" is an instruction.

The most common failure is instructions that are a wish list of adjectives. They feel like configuration and do nothing.

Weak instructions

You are a helpful, professional, and accurate assistant. Be thorough and detailed in your responses. Always provide high-quality, well-organized answers. Be concise but complete. Use your best judgment.

Every word of that is true of Claude already. "Be accurate" is not a standard Claude can measure itself against, and "use your best judgment" is precisely the instruction to stop; it hands back the decisions you were supposed to make. This configures nothing.

Strong instructions

You are reviewing commercial contracts on behalf of us as the buyer. The reader is our head of finance, who is not a lawyer. For every contract I share, work in this order: 1. List each clause covering payment terms, liability, or termination, with its clause number. 2. For each, flag whether it deviates from our standard terms (in the knowledge base) and rate the risk to us: High / Medium / Low, with a one-line reason. 3. Only then write a summary, leading with the highest-risk items. Use plain language a non-lawyer can act on. Never soften a High risk to sound reassuring. If a contract raises a question our standard terms and playbook don't address, say so explicitly and tell me what a lawyer would need to review. Do not guess at our position.

Read the difference. The strong version encodes a role, an audience, a repeatable method, the exact criteria for judging risk, and (the load-bearing final paragraph) what to do at the edge of what the knowledge supports. None of it mentions a specific contract, because it applies to all of them.

Try it in Claude

Open your Project's instructions and write a first draft covering role, audience, output conventions, your recurring criteria, and a failure instruction. Keep it about method, not today's task.
Start a chat in the Project and give it a representative task. Read the output against your instructions: did it adopt the role? Follow the order? Use your criteria without being reminded?
Find the gap. If it drifted formal when you wanted plain, or skipped a step, that's an instruction that was implied but not stated. Edit the instructions (not the chat) and start a fresh conversation to test the fix.
Repeat until a cold chat, with no extra prompting, produces something you'd actually use. That's your instructions working as configuration.

3. Curating Knowledge Sources

The instinct on knowledge is to dump everything in (every deck, every version, every related doc) on the theory that more context can't hurt. It can, and it does. More is not better; authoritative is better.

When two uploaded documents disagree, Claude has no way to know which one you consider current. It can't see that the file named "final_v2" supersedes the one named "final." So it may reason from the stale one, blend the two, or answer confidently from whichever it read, and you'll never see which. Bad, outdated, or contradictory documents don't sit there harmlessly. They actively degrade output.

Upload the authoritative version only. One source of truth per topic. Delete the drafts and the near-duplicates before they get read.
Remove superseded documents the moment they're superseded. A Project's knowledge is not an archive. If a policy was replaced, the old policy is not history; it's a landmine.
State precedence when overlap is unavoidable. Sometimes two sources genuinely both belong. Then say so in the instructions: "If the pricing sheet and the master agreement disagree, the master agreement governs." You've given Claude the tiebreaker it otherwise lacks.

More knowledge is not better knowledge. A Project with three current, authoritative documents outperforms one with thirty documents of mixed vintage, every time. Each stale or redundant file adds a way for Claude to be confidently wrong, and none of them add a way for it to be right that the authoritative version didn't already cover. Curate down, not up.

Try it in Claude

Upload one real reference document to your Project's knowledge: a policy, a style guide, a standard-terms sheet, a product FAQ.
Ask a chat a question the document does answer. Confirm Claude uses it: the answer should reflect your document's specifics, not generic advice.
Now the important test. Ask a question your document plainly does not cover, something adjacent but genuinely outside it. A well-configured Project, with the failure instruction from section 2, should tell you it can't find that in the knowledge rather than inventing an answer.
If it invented an answer instead of declining, go back to your instructions and strengthen the failure line, then retest. This refusal behavior is the whole point of grounding Claude in curated knowledge, and the exam tests it directly.

4. Uploads vs. Connectors

Knowledge comes in two forms, and choosing between them is a judgment the exam expects you to make deliberately. An upload is a document you add to the Project, a frozen snapshot. It says exactly what it said the moment you uploaded it, forever, until you replace it. A connector (Google Drive, Gmail, and similar) gives Claude live access to material that changes: the current contents of a folder, recent email, files as they stand right now.

Connectors buy freshness. You never have to remember to re-upload the latest version because there is no upload; Claude reads the source. But that same live reach is the cost: a connector widens the surface of what Claude can see into a system that changes without your knowing, and "what did Claude actually read" becomes harder to pin down. An upload is bounded and auditable; you know precisely what's in it because you put it there.

	Uploaded knowledge	Connector (Google Drive, Gmail, …)
Freshness	Frozen at upload; stale until you replace it	Live; reflects the source as it changes
Scope control	Exactly the files you added, nothing more	As wide as the access you granted; can reach material you didn't have in mind
Auditability	High — you know precisely what's in the Project	Lower — the source shifts, so "what was read" is a moving target
Best for	Stable references: policies, standard terms, style guides, a manual frozen for the quarter	Fast-moving material: an active project folder, this week's correspondence, anything you'd otherwise re-upload constantly

The rule of thumb: if the source changes faster than you'd remember to re-upload it, lean connector. If the source needs to stay exactly as it is until you deliberately change it (a compliance manual frozen per quarter, a contract template), upload it, so it can't drift underneath you.

Freshness and control are a trade, not a free lunch. Every connector you attach makes the Project more current and less bounded at the same time. Attach the ones whose material genuinely moves; for anything stable, an upload gives you a snapshot you can point to and say "this, exactly, is what Claude was working from."

5. Maintenance: the Objective Everyone Forgets

Here is the part people skip, and it's an explicit exam objective: a Project is not a one-time setup. The day you build it, it's perfect. Then the policy changes, the team reorganizes, the product ships a new tier, the style guide gets rewritten, and none of that reaches your Project unless you carry it there. Knowledge goes stale, instructions drift out of sync with how the team actually works.

And a stale Project is worse than no Project. A blank chat makes you supply current context, so you notice when something's changed. A stale Project confidently answers from last quarter's policy, in a trusted workspace, and everyone downstream believes it. It launders outdated information as authoritative. That's the failure mode maintenance exists to prevent.

Maintenance is a discipline with two triggers, the calendar and the event:

Review on a cadence. Put a recurring date on it. Monthly for fast-moving Projects, quarterly for stable ones. On that date you re-read the instructions and check every knowledge source against reality.
Review on trigger events. Don't wait for the calendar when something material happens: a policy change, a reorg, a product launch, a rewritten template. The event is the trigger.
Version the instructions. When you change them, note what changed and when, so you can tell whether a behavior shift came from your edit or from something else.
Remove knowledge that no longer holds. The same rule as curation, applied over time: the moment a document stops being true, it stops belonging in the Project.

Trigger event	What to check	Action
A policy or standard-terms document is revised	Every uploaded copy of the old policy, and any instruction that quotes it	Replace the upload with the new version; delete the old; update the instruction wording
Team reorg or new audience for the output	The role and audience lines in the instructions	Rewrite so the stated reader matches who actually consumes the output now
Product launch or pricing change	Product FAQs, pricing sheets, feature lists in knowledge	Add the new authoritative doc; remove superseded ones; check precedence rules still hold
Scheduled cadence date arrives	Every knowledge source's currency and every instruction's accuracy	Confirm still-true items, refresh stale ones, delete dead ones, and log the review date
Output quality quietly slips	Whether knowledge or instructions have drifted from current reality	Trace the bad answer to its stale source and correct that source, not just the one chat

When to escalate. Everything in this lab is you, by hand, in claude.ai. You cross out of Associate territory the moment the requirements change shape: when knowledge must sync automatically from an internal system so no human has to re-upload it, when access to that knowledge must be governed per-user so different people see different things, or when you're building a retrieval system that fetches the right documents on its own. That is design and engineering work for a Claude Architect or Developer. Recognizing that line (and handing off rather than improvising past it) is itself an exam objective.

6. Lab Exercise: Build a Real Project for Your Own Role

Objective: stand up a Project you'll actually keep using (seeded with the winning prompt you saved at the end of Lab 1) and prove it starts smart, uses its knowledge, and refuses what it can't answer.

Pick the recurring job. Choose one kind of work you do repeatedly, the thing you keep re-explaining to Claude. Create a Project named for it.
Promote your Lab 1 winner. Retrieve the strong prompt you saved. Pull the reusable parts (the role, the criteria, the failure instruction) up into the Project's custom instructions, rewriting them from "do this one task" into "here's how to work." What changes per task stays out of the instructions.
Add role, audience, and output conventions if your Lab 1 prompt didn't carry them. State who Claude acts as, who reads the result, and what every output should look like.
Curate one or two authoritative documents into the knowledge. Only current, true, non-overlapping sources. If two could conflict, add a precedence line to the instructions.
Decide uploads vs. connectors for each source using the table in section 4. Frozen reference → upload. Fast-moving material you'd re-upload constantly → consider a connector, accepting the wider scope.
Test the happy path. Cold chat, representative task, no extra prompting. It should produce something usable on the first try. If not, fix the instructions, not the chat.
Test the refusal. Ask something the knowledge genuinely can't answer. Confirm it says so instead of inventing. If it invents, strengthen the failure instruction and retest.
Set the maintenance trigger. Put a review date on your calendar and write one line at the top of the instructions: what version this is, and what event would force an early review. You've just built the thing Lab 8 will have you ship.

Check Yourself

Exam-style items. Commit to an answer before expanding.

A team relies on a Claude Project for HR policy questions. Last month the parental-leave policy changed, but the Project keeps giving the old entitlement, confidently, and people are acting on it. What is the correct fix?

A. Add a line to each chat reminding Claude the policy changed.
B. Replace the outdated policy document in the Project's knowledge with the current version, remove the old one, and update any instruction that referenced the old terms.
C. Tell users to double-check Claude's answers against the real policy.
D. Delete the Project and have everyone use plain chats instead.

Correct: B. The Project is producing confidently outdated answers because its knowledge is stale, the exact failure maintenance exists to prevent. A policy change is a trigger event: replace the superseded document with the authoritative current one, delete the old copy so it can't be read, and reconcile the instructions. Fix the source, and every future chat is correct.

A patches one conversation while the root cause (the stale document) keeps poisoning every other chat. C shifts the burden to users and concedes the Project can't be trusted, which defeats its purpose. D throws away a genuinely useful tool to avoid maintaining it; the problem isn't that Projects exist, it's that this one wasn't kept current.

While configuring a Project, an associate uploads two pricing documents. They disagree on the enterprise tier's price: one is a superseded draft, the other is final. What's the best action?

A. Leave both and let Claude weigh them; more context is safer.
B. Leave both, but add an instruction saying "prefer the more accurate one."
C. Remove the superseded draft so only the final, authoritative pricing document remains in the knowledge.
D. Upload a third document explaining the history of the pricing change.

Correct: C. Claude can't tell which of two conflicting documents you consider authoritative, so a contradiction in the knowledge is a direct route to a confidently wrong answer. With one superseded and one final, there's no genuine overlap to preserve; the fix is curation: delete the draft, keep the single source of truth.

A is the "more is better" fallacy the domain explicitly rejects; the extra document only adds a way to be wrong. B tells Claude to "prefer the more accurate one," which is a wish, not a rule; Claude has no way to know which is accurate, that's the whole problem. D adds even more conflicting text; the goal is one authoritative source, not a paper trail of superseded ones.

An associate is setting up a Project for compliance queries. The reference is a regulatory manual that is deliberately frozen at the start of each quarter; it must not change mid-quarter, and auditors may later ask exactly what version was in use. Upload or connector?

A. A Google Drive connector, so the manual is always the latest version.
B. Upload the quarter's manual as a document, replacing it deliberately at the start of each new quarter.
C. A connector, because connectors are always preferable to uploads.
D. Both a connector and an upload of the same manual, for redundancy.

Correct: B. The requirement is a frozen snapshot plus auditability: the manual must stay exactly as it is until the quarter turns, and you must be able to say precisely what was in use. That's the textbook case for an upload: bounded, unchanging until you deliberately replace it, and fully auditable. You control the swap at the quarter boundary.

A actively breaks the requirement: a connector's live sync means the manual could change mid-quarter, which is the one thing that must not happen. C states a false rule; neither form is universally better, the source's behavior decides. D combines a controlled snapshot with a live one that can drift, reintroducing the contradiction risk and muddying which version was authoritative.

Key Takeaways

A Project makes recurring work start from context instead of a blank page. Use a chat for one-offs; use a Project when you do the same kind of work repeatedly.
System-level instructions state role, audience, and output conventions; encode your recurring criteria; tell Claude what to do when the knowledge can't answer; and describe how to work, not a single task. A wish list of adjectives configures nothing.
Curate knowledge down, not up. Upload the authoritative version only, remove superseded documents, and state precedence when overlap is unavoidable; contradictory sources actively degrade output.
Uploads are frozen, bounded, and auditable; connectors are live but wider and harder to audit. Match the choice to whether the source should stay fixed or stay current.
Maintain on a cadence and on trigger events. A stale Project is worse than none; it launders outdated answers as authoritative. Escalate when knowledge must sync automatically, be governed per-user, or drive a retrieval system.