Projects as a Knowledge Base

Think about what actually makes Claude useful on a real job. It is rarely the raw model - it is the model plus context: this client, this brief, the way your practice words a finishes schedule, the standards you always cite, the tone your director insists on. In a plain chat you supply that context by hand, every time, and it evaporates the moment the conversation ends. That is fine for a one-off question. It is a quiet disaster as a way to run a studio, because the quality of every answer now depends on whether the person at the keyboard remembered to paste the right context - and no two people will.

A Project is Claude's answer to this. It is a persistent workspace with two parts: project knowledge - the files and text you upload once (a spec template, your drawing-notes library, a style guide, past reports) - and custom instructions, a standing brief that tells Claude who it is working for and how to behave. Every new chat inside the Project inherits both. The junior who joined last week opens the same Project as the associate of ten years and both start from the same, current, agreed baseline.

The payoff is threefold. Consistency: a spec drafted from the studio template reads like the studio, whoever prompted it. Speed: nobody re-types the brief; you go straight to the question. Institutional memory: the way your best people word things stops living only in their heads and becomes an asset the practice owns. This is close in spirit to what engineers call retrieval-augmented generation - grounding a model on your own trusted documents rather than its general training - except you are doing it by hand, deliberately, with material you have chosen and vetted.

One honest caveat from the start: a Project is only as good as what you put in it, and it is shared. A wrong figure or an outdated template in project knowledge now propagates to everyone with quiet authority. So the discipline of this lesson is not just loading a Project - it is curating and maintaining one.

A good studio Project is a curated shelf, not an attic. The temptation is to dump everything in; resist it, because a Project stuffed with contradictory or irrelevant files makes Claude's answers worse, not better. Aim for a small set of current, canonical documents plus a tight custom-instructions brief.

The things that earn their place fall into a few families. Standards and references you cite repeatedly - your house specification clauses, standard drawing notes and general conditions, the list of codes you work to. Templates - the skeleton of a proposal, a stage report, a finishes schedule, a meeting-minutes format. Past exemplars - two or three genuinely good, finished specs or reports that show Claude the target quality and voice (not fifty mediocre ones). And a brand-voice note - a short, blunt description of how the practice writes: plain or lyrical, British or American spelling, first person plural or impersonal, what words you never use.

The custom instructions are where you set the standing behaviour. Keep them concrete:

You are drafting for [Practice], a [city] architecture studio.
Audience: our clients (intelligent, not technical) and consultants.
Voice: plain, warm, precise. British spelling. First person plural ("we").
Never invent standards, dimensions, prices or clause numbers - if a
figure is needed and not supplied, insert [VERIFY] and ask.
When you draft a spec or schedule, follow the template in project
knowledge exactly. Flag anything you are unsure about at the end.

That last instruction matters more than any template: a standing rule that Claude marks the unverified rather than smoothing over it. Notice it bakes the whole course's spine - plausible is not true - into the workspace itself.

What does not belong is just as important. Do not load confidential client material into a Project that others can open, or into any Project without first checking your plan's data settings - on consumer plans, content may be used to improve the model unless you have opted out, so client-sensitive work belongs on business or enterprise terms and behind proper access. Do not load a document you have not read and trust. And do not treat the Project as a graveyard for superseded versions; one live template beats five and their ghosts.

A knowledge base that nobody maintains rots, and a rotted Project is worse than none because it lies with confidence. So treat a studio Project the way you treat a drawing register: named, versioned, owned and reviewed.

Naming. Give Projects and the files inside them names a stranger could parse: Practice - House Spec Template v4 (2026-08) beats spec final FINAL. Put a date and a version in the filename of anything that changes, so the moment someone sees v3 next to v4 they know which is live. A one-line note at the top of each document - what it is, when it was last checked, by whom - saves hours of doubt later.

Versioning and a single source of truth. Decide, per document, where the master lives. If your finishes-schedule template is maintained in a shared drive, the Project should hold the current export of that master, not a fork that drifts. When the master changes, someone updates the Project. Without this rule you get two truths, and Claude will happily cite the wrong one.

Ownership. Name a custodian for each shared Project - usually whoever owns that domain in the practice (the spec Project belongs to your technical lead; the bids Project to whoever runs proposals). Their job is small but non-negotiable: keep it current, prune the stale, and re-read the custom instructions every quarter.

Hygiene routine. Put a recurring calendar entry - quarterly is enough for most studios - to open each shared Project and ask three questions: Is every document still current? Has anything superseded a file in here? Do the custom instructions still describe how we actually work? Delete or replace anything that fails. This is dull and it is the whole game: a Project you trust is one someone is responsible for.

A useful test before you rely on a shared Project: open a fresh chat inside it and ask, "Using only the project knowledge, draft a finishes schedule for a small bathroom." If the output is on-template, on-voice and free of invented figures, the base is healthy. If it drifts or fabricates, your knowledge or your instructions need work - better to learn that now than on a live job.

A single Project is a good start; a studio runs on a small, deliberate set of them. The wrong instinct is one giant Project holding everything - it becomes a junk drawer, and Claude's answers blur because the context is contradictory. The right pattern is a few Projects scoped by job, each lean.

A workable shape for most practices has three layers. A practice-wide Project holds the things true of every job: voice, standard notes, house templates, the codes you always work to. A per-client Project (for repeat or major clients) adds their preferences, past correspondence and brand. A per-project Project holds the live job: this brief, this site, this program - and it can borrow the practice templates by having them re-loaded or referenced. Most day-to-day work happens in the per-project workspace, standing on the practice-wide foundation.

Be honest about the plan constraints. Projects are a paid-plan feature, and the number of Projects, the size and count of uploads, and the strength of the data terms all vary by plan and change over time - business and enterprise plans add the admin controls and data protections a studio handling client work actually needs. Decide your structure around what your plan offers today, and revisit it as both the plans and your practice change.

The deeper point is cultural. Once the knowledge lives in shared Projects rather than individual heads, the practice can improve it deliberately - a better spec template helps everyone the day it lands, a clarified voice note fixes drift across the whole studio at once. That is the shift from personal habit to studio standard, and every remaining lesson in this module builds on it: reusable prompts (9.2) live beside the knowledge they act on, team rollout (9.3) depends on everyone sharing the same base, and quality control (9.4) is far easier when the starting material is consistent.