Putting the intake somewhere it gets used

You have a completed BV-01. Right now it is a file, and a file you have to remember to open is only slightly better than a rule you have to remember.

This is the step the intake form is referring to when it says the Project is "the workspace you set up earlier in this module." This is that step.

1The mechanics are in Module 2 §8 — read that first if you skipped it

08-projects-and-context.md covers what a Project is, what goes in the knowledge base versus the instructions, the free-plan capacity of five, and the fact that a project's name and description are not visible to Claude. None of that is repeated here.

What this section adds is the part that only makes sense once you have a filled-in BV-01 in your hand: the order you do it in, and what to test afterwards.

2Set it up — about ten minutes, once per client

1. New Project, named for the client. Not for the campaign. Campaigns end; the brand's rules don't.

2. Upload intake.md — your completed BV-01 — to the knowledge base. Part-filled is fine. The gaps are information too.

3. Upload your experience file, the record from §3 of what you actually did with the product, including the what I did not record list. If it doesn't exist yet, this is a much better moment to discover that than mid-deadline.

4. Add anything else you'll otherwise search email for: the signed brief, the contract extract with the barred-claim wording in the client's own words, previously approved scripts.

5. Set project instructions. These are behavioural, not reference — the intake is the facts, the instructions are the conduct:

   Plain text4 linesCopy

   Every script in this project is for [CLIENT]. Read intake.md before writing
   anything. Never write a claim that isn't in experience.md. If the intake is
   silent on something, say so and ask — do not infer the brand's position.
   Run claim-guard before presenting any draft as finished.

   Short, and it restates the two refusals so the standard holds even in a chat where you forgot to invoke the skills.

6. Test it, and test it properly. New chat inside the project, then ask:

   "What may I not say for this client, and what am I contractually required to include?"

   Read the answer against the form. If it's wrong or vague, the finding is about your intake, not about the tool — go and fix the file. This test takes thirty seconds and it is the only way to find out whether what you wrote is actually usable by anyone other than you.

3Now the thing that will actually catch you

Module 1.5 planted this and Module 2 §8 built a workflow on it. Module 3 is where it stops being a concept.

Here is the failure, in the shape it will arrive.

You are in a chat with the client's project loaded, writing scripts. The client emails mid-session: "we've stopped saying 'artisan' — drop it." You tell Claude. It adapts, correctly, for the rest of the conversation. The scripts come out right. You ship them. Good day.

Next Tuesday you open a new chat in the same project and every script says "artisan."

Nothing broke. The rule lived in a conversation. The knowledge base never changed, so as far as the next chat is reliably concerned the rule was never made.

There is an opt-in memory feature, and each project has its own memory space, so it's possible the rule surfaces anyway. That doesn't rescue you, and Module 2 §8 gives the exact reason:

A memory is a summary. A knowledge base is a file.

A guardrail you cannot produce on request is not a guardrail.

Memory is unversioned and uninspectable. You cannot show it to a client, cannot diff it, cannot say which revision a script was written against. For "this creator prefers short sentences" it's fine. For a contractual bar it is not — and not because it might fail, but because you couldn't demonstrate it hadn't.

The habit

And note the mechanical reason this bites: uploading a file to project knowledge takes a copy. Editing the original in your drive does not update what the project sees. Re-upload, every time.

4The three places the finished intake goes

The intake tool's filed copy names all three, and they're worth separating because they have different failure modes:

All three are the same file. The revision letter is what keeps them honest — which is why §2 says to bump it when a rule changes.

5One project per client, and don't merge

Module 2 §8 covers the capacity: five projects on a free account, unlimited on paid, and five active clients is a real working capacity rather than a trial.

The rule that matters regardless of plan: do not merge two clients into one project. One brand's off-limits list applied to another brand's script is the specific failure this entire module exists to prevent, and it happens quietly.

If you need to free a slot before upgrading, archive a dormant client and re-create it from the intake file when they come back. That takes about ten minutes, because the intake is the project.

6What you have at the end of this module

Per client: a completed BV-01, a record of what you actually did with the product, a Project with both loaded, and instructions that restate the refusals.

What that buys you is the thing the module opened with. You can now write for a client you last thought about six weeks ago without re-reading an email thread, and you can hand that client to somebody else without a handover call.

Module 4 is next, and it takes the checking discipline from §3 and turns it into something you can show a prospect.