Build a Standing Schema Knowledge Base With a Claude Project

Before uploading anything, get clear on what this project should and shouldn't contain.

1. Good candidates: dbt schema.yml files, model documentation, architecture decision records, data dictionary pages, ER diagrams exported as text or PDF.
2. Bad candidates: anything containing real customer rows, account numbers, or other production data, even as an example. This project should describe your schema's structure, not carry samples of what's actually in it.

1. Open Projects from the sidebar in Claude.
2. Click "New project."
3. Fill in what the project is for, something like "Data warehouse schema reference for the analytics team," and what you're trying to achieve with it.

What you should see: A new project workspace with fields for custom instructions and a Files panel for uploads.

1. In the project's custom instructions field, describe how you want Claude to answer questions in this project. For example: "You are a reference assistant for our data warehouse schema. Answer based on the uploaded documentation. If something isn't covered in the files, say so rather than guessing."
2. Save the instructions.

Why this matters: Without this, Claude may fill gaps with plausible-sounding guesses instead of telling you the docs don't cover something. The instruction to admit what it doesn't know matters more here than in a casual chat.

1. Open the Files panel inside the project.
2. Upload your dbt docs, schema.yml files, data dictionary pages, and architecture notes. PDF, Markdown, plain text, and code files are all supported, along with DOCX, CSV, and HTML.
3. Start with your most-asked-about tables and models rather than trying to upload your entire warehouse's documentation on day one.

What you should see: Uploaded files listed in the Files panel, available to every chat started inside this project.

Troubleshooting: If a file is too large, split it into smaller documents (by domain or by model group) rather than one giant export. Smaller, well-organized files also tend to produce more precise answers than one enormous dump.

1. Start a new chat from inside the project.
2. Ask something you already know the answer to, so you can check accuracy before relying on it for real. For example, "what does the customer_tier column in dim_customers represent, and which model calculates it."
3. Compare the answer against what you know to be true.

What you should see: An answer that references your actual uploaded documentation, not a generic explanation of what a customer tier column might typically mean.

1. When you update a model's documentation in dbt, update the corresponding file in this project too. A stale knowledge base is worse than no knowledge base, since people trust it by default.
2. Set a recurring reminder, monthly is reasonable, to re-export and re-upload your dbt docs so the project doesn't drift too far from reality.