4. The Brand Guide Built From Passed and Rejected Drafts

Turning the facts sheet into a register

A standard only helps when a draft can be checked against it. Ledgerlane's product-facts sheet, which lists the one-van and two-van prices, four inclusions, three exclusions and onboarding "about two weeks from signing", becomes a register. Each fact gets its own row with a claim, value, source, named owner, date last checked, and status. Conditions like "from signing" stay inside the value. A header gives the file's owner and its next full check. Clearly labelled sections, as Anthropic's prompting guidance recommends, let Ida see where one fact ends and the next begins.

Why a stale file slips through

A Claude Project treats every uploaded file as available knowledge. A newer upload does not replace an older one. When two files disagree, Claude may blend them, hedge, or pick one. The result is a confident email quoting last year's price. There are three fixes. Keep one current register. Delete the old file before uploading the new one. Tell the project instructions to use only current rows, to ask when sources conflict without dates, and to list the rows each draft used. A fresh-chat audit then confirms the project is clean. Instructions guide the model, but only removing the old file removes the risk.

A brand guide built from what passed and failed

Adjectives like "friendly" and "clear" rule nothing out. Paired examples do. Two pieces of accepted work are included: the plain onboarding email and the corrected hero section. Two rejected pieces sit beside them. One is the "stress-free, hassle-free" ungrounded draft. The other is an on-voice benefit sentence with no customer evidence behind it. Ida drafts seven rules, each tied to an example. Two get cut: "light humour" and "warm, approachable tone". Five checkable rules remain. The guide is laid out as a dated header, a who-we-sound-like description, phrases to use and avoid, the rules, and the side-by-side pairs.

Testing both on a fresh request

A fresh chat produces an FAQ answer for a two-van contractor. It passes on voice, but it states the price "including VAT", and no register row supports that. The phrase is removed. A new VAT row is added with its status left open, assigned to the founder to confirm.

Keeping files current across assistants

OpenAI is retiring Custom GPTs on 11 December 2026 and moving them to Plugins and Skills (migration FAQ). Skills are called up only when ChatGPT judges them relevant, so voice rules may not apply every time. Rerun the fact-listing audit after migrating. Gemini Gems can silently fail to read complex PDFs or oddly named files. Plain text with clear headings is safer.

A standard only helps when it can be checked

The audience-and-offer brief is saved. It sits in the Ledgerlane Marketing project next to the hero section and the customer-language evidence file. Every element in it points back to a line number or a product fact. That brief tells Ida who the message is for and what it offers. It does not yet protect two things that every later draft will lean on: the facts themselves, and the way Ledgerlane sounds.

This chapter builds those two protections. The first is a product-facts register. The second is a brand guide made of real work that passed and real work that failed. Both follow one idea. A standard only helps when someone can check a draft against it. "Our prices are accurate" cannot be checked. "Two vans cost two hundred and sixty pounds a month, confirmed on this date by this person" can. "Our tone is friendly and clear" cannot be checked either. "This email was accepted, this draft was rejected, and here is why" can.

The companion segment has already built a reusable brand brief and tested it in a fresh chat. That brief described voice, claims, examples and which source wins. What follows goes two steps further. The register keeps track of which facts are current and who vouches for them. The guide teaches through contrast, so Ida can see where the edge of the voice is.

As always in this course, Ledgerlane is illustrative. The prices, dates, owners and example drafts below are invented to make the method visible. They are not facts about any real firm.

The facts sheet becomes a register

Start with what already exists. In the first chapter the source packet got a product-facts sheet. It says one van costs a hundred and eighty pounds a month, and two vans cost two hundred and sixty. It lists four things included: receipt photo capture, monthly bank reconciliation, quarterly VAT preparation, and tax-ready year-end accounts. It lists three things excluded: payroll, chasing unpaid invoices, and advice on whether to incorporate. And it says onboarding takes about two weeks from signing.

That sheet worked for one hero section. It has a weakness, though. It is a paragraph of facts with no history. Nothing on it says when each fact was last true, who confirmed it, or where it came from. That is fine on the day you write it. It stops being fine the first time something changes.

So the sheet becomes a register. A register is just a list where every fact gets its own row, and every row carries the same few pieces of information. For Ledgerlane, each row has six parts.

The first part is the claim, said plainly: "monthly price for one van". The second is the value: "one hundred and eighty pounds a month". The third is the source, meaning the document or system where the fact really lives. For the prices, that might be Ledgerlane's current price list. For onboarding, it might be the onboarding checklist the team actually uses. The fourth is the owner, a named person who can say yes, that is still true. In our illustrative firm, the founder owns prices and scope, and the person who runs onboarding owns the timing. The fifth is the date last checked. The sixth is the status, which is either current or retired.

Walk through the rows. Price for one van: a hundred and eighty pounds, from the price list, owned by the founder, checked on the twenty-second of September, current. Price for two vans: two hundred and sixty pounds, same source, same owner, same date, current. Then one row for each inclusion and one row for each exclusion. That is seven more rows. Splitting them matters. If payroll ever moves from excluded to included, you change one row, and the date on that row tells you when. Last comes onboarding: "about two weeks from signing", from the onboarding checklist, owned by the onboarding lead, current.

Notice that the onboarding row keeps the words "from signing" inside the value. In the first chapter, Ida dropped that qualifier and the draft promised something slightly different. Putting the condition inside the fact makes it part of what gets copied. A register row should hold the whole claim, conditions included. The short version should never be what gets stored.

At the top of the register sits a small header. It names the file's overall owner, the date of the last full check, and when the next full check is due. Monthly suits a small firm whose prices rarely move. The header answers one question fast: how old is this, as a whole?

Research on structuring reference files for Claude suggests one more thing. Mark the boundaries of each section so the assistant can tell them apart. Anthropic's own prompting guidance recommends labelled tags for this. You do not need to write code. It is enough to give the register clear, labelled sections, one per fact, each with the same fields in the same order. The point is that Ida can see where one fact ends and the next begins, and which field is the date.

What a stale file actually does

Here is why the dates and statuses are worth the trouble. Suppose that in January Ledgerlane raises the one-van price to a hundred and ninety-five pounds. Someone writes a new facts sheet and uploads it to the project. The old sheet is still there. They meant to tidy it later.

What does Claude do now? It helps to know how a Claude Project handles its files. When the files are small enough to fit, which a few pages of Ledgerlane material easily are, Claude reads all of them into the conversation as background. When the files grow very large, past roughly two hundred thousand tokens, Claude switches to retrieval. Retrieval means it searches the files for the pieces that look relevant and reads only those. Either way, every file in the project counts as available knowledge.

Three details matter here.

First, Claude does not treat a newer upload as a replacement. Upload time is not a signal it uses to decide which file is true. Two files that disagree are, to Claude, two pieces of equally valid context.

Second, there is no overwrite. If you upload "facts sheet, January" while "facts sheet" is still in the project, you now have two files. Both are active.

Third, when two active files disagree, the result is not a clean error. Claude may blend them, hedge with "from about a hundred and eighty pounds", or simply pick one. Which one it picks can depend on where the text sits in its context or what it happens to weigh more. In a long chat there is a further drift. As the conversation grows, older material can get compressed, and recent chat turns can end up counting for more than the background files.

Put that together and you get the failure the register exists to prevent. Ida writes a smooth, confident email that quotes a hundred and eighty pounds. The sentence reads well. The tone matches the brand. Nothing about it looks wrong. The only way to catch it is to know that the price changed. A reader skimming for tone will not.

This is the pattern from earlier chapters, now over time. A claim only counts when its source can be named. A source only counts when it is still the current one.

The rule for keeping it current

The fix is simple, and it has three parts.

There is one current register in the project. Not a register plus last quarter's sheet. Not a register plus the original packet's facts sheet "just in case". One.

When the register changes, the old file comes out before the new one goes in. In Claude, you delete the outdated file from the project knowledge panel, then upload the revision. Deleting first means Claude stops drawing on the old version. It also means there is never a moment when both are live. If you want a history of past prices, keep it outside the project, in your own records. Inside the register, a row whose status is "retired" can stay briefly to show what changed. The safer habit is to move retired rows out too. Anything in the project is something Ida can quote.

The project instructions point to the register first. The standing instructions for Ledgerlane Marketing gain a short passage on facts. In plain words it says this. For any price, inclusion, exclusion or timing, use the product-facts register and only its rows marked current. If two sources in the project disagree, the one with the more recent checked date wins. If they disagree and neither has a date, or both have the same date, stop and ask me rather than choose or blend. Never state a price, feature or timing that has no row in the register. At the end of any draft, list which register rows you used and their checked dates.

That last instruction is small but useful. It turns every draft into something you can audit. If the footnote lists "one-van price, checked twenty-second of September", and you know the price changed in January, you have caught the stale fact without rereading the whole draft.

One more habit closes the loop. After any change to the project's files, open a fresh chat in the project. Ask Ida to list every current fact she can see, with its value, source and checked date, and to flag any two facts that disagree. A fresh chat matters because it carries no earlier conversation that might mask the files. If the list shows two prices for one van, a stale file is still in there. If it shows the new price with the new date and nothing else, the project is clean.

Instructions are guidance to the model, not a lock. The precedence rule makes a good outcome much more likely. It does not make a contradictory file harmless. Removing the old file is what actually removes the risk. The instruction is there for the day someone forgets.

The brand guide, taught through what passed and what failed

The register settles what Ledgerlane can say. The brand guide settles how it says it. A guide made of adjectives rarely constrains an assistant much, so this one is built from something firmer.

Think about what an adjective asks the model to do. Tell Ida that Ledgerlane is "friendly, clear and professional". Each of those words covers a wide range of writing. Nearly all marketing copy would call itself friendly, clear and professional. That includes the kind that opens with "Say goodbye to tax-season stress!" So when Ida reads those adjectives, she fills them in with the most common version of them. That is the generic marketing voice the course has been steering away from since chapter one. The adjectives are not wrong. They just do not rule anything out.

An example rules things out. Show Ida a real onboarding email and say "this passed". She sees the sentence length, the missing compliments, how numbers are stated. Show her a rejected draft next to it and say "this failed, because it flatters the reader and promises what the service does not do". Now she can see the boundary from both sides. The contrast carries information that neither example carries alone.

Collecting the accepted work

Ledgerlane already has two pieces of accepted work.

The first is the onboarding email excerpt from the original source packet. It is the course's brand example: short, plain, unflattering sentences. An illustrative line in its style reads: "We'll need your last three bank statements by Friday. If you can't find them, tell us and we'll ask the bank." It says what is needed, when, and what happens if there is a problem. It does not say "we're so excited to work with you". The reason it passed, in plain words: it tells a busy contractor exactly what to do next and assumes they are competent.

The second is the corrected hero section from chapter one. After its two fixes, it stated the onboarding time with "from signing" attached and named what the service does not cover. The reason it passed: every claim traces to a fact, the conditions stay attached to the numbers, and the exclusions are said out loud rather than hidden.

Collecting the rejected work

Now the failures, which are just as useful.

The first is the ungrounded draft from chapter one. That was the one written from a bare request outside the project. It had the wrong business name, invented claims, a wrong price, and a call to action that did not match the goal. An illustrative line in its style: "Experience stress-free, hassle-free bookkeeping tailored to your unique business needs." The reasons it failed, in plain words: "stress-free" is a promise no fact supports; "tailored to your unique needs" describes any service at all; and the line says nothing a contractor could check.

The second is the faulty benefit sentence from Ida's first draft of the audience-and-offer brief. It was one of the three faults caught there: a benefit with no citation behind it. It read smoothly. It sounded like the brand. But it did not come from the evidence file's own words. The reason it failed: it claimed a feeling customers never described, which made it sound right while being unsupported.

That second rejection is worth holding onto. A brand guide made only of obvious failures teaches Ida to avoid obvious failures. The benefit sentence failed for a quieter reason. It was on-voice and still ungrounded. Including it teaches that sounding like Ledgerlane is not enough.

Label all four in the guide as illustrative examples of the method. That keeps them honest when someone else reads the file later.

Letting Ida draft the rules, then cutting

With four examples and four stated reasons in hand, ask Ida to draft voice rules. The request is roughly: "Using only the accepted and rejected examples in the brand guide and their stated reasons, write voice rules for Ledgerlane. For each rule, name which example supports it."

That last clause does the work. It makes every rule answer to evidence, the same way the brief's claims answer to line numbers.

Say Ida returns seven rules. Check each against the examples.

"State numbers with their conditions attached." Supported by the corrected hero section, which kept "from signing", and by the rejected draft's wrong price. Keep it.

"Name what the service does not cover." Supported by the hero section's exclusion line. Keep it.

"Do not compliment or reassure the reader in place of information." Supported by the onboarding email, which does neither, and by the rejected "stress-free" line, which does both. Keep it.

"Keep sentences short and tell the reader what to do next." Supported by the onboarding email. Keep it.

"Every benefit must use words customers actually used, with its source named." Supported by the rejected benefit sentence. Keep it.

"Use light humour to build rapport." Which example supports it? None. The onboarding email is not funny, and nothing in the rejected pile failed for being too serious. This rule came from Ida's general sense of what brand guides say, not from Ledgerlane. Cut it.

"Maintain a warm, approachable tone." This is the adjective problem sneaking back in. No example shows what "warm" means for Ledgerlane that the other rules do not already cover. Cut it, or rewrite it as something checkable. In this case the no-compliments rule and the short-sentences rule already carry it. Cut.

Five rules survive. Each can be checked against a draft by pointing at a sentence.

How the guide is laid out

Research on brand guides that work well with assistants points to a clear structure. Ledgerlane's guide follows it.

At the top sits a small header: a version number, the date it was last updated, and the channels it covers. For now that means the website and customer emails. The date plays the same role as the register's dates. If two versions of the guide ever end up in the project, the date says which one is current. The same delete-before-upload rule applies.

Next comes a short description of who Ledgerlane sounds like, written as what it is and what it is not. Here that is: a competent person who does this work every week, talking to another competent person who is busy. Not a cheerleader. Not a textbook.

Then a short list of phrases to use and phrases to avoid. The avoid list comes straight from the rejected examples: "stress-free", "hassle-free", "tailored to your unique needs". Add any stock phrase that shows up in a rejected draft later.

Then the five rules, each with its supporting example named.

Last, the paired examples. Accepted and rejected sit side by side, each with its one-sentence reason. This section does most of the teaching. The rules summarize it. The pairs show it.

Save the guide in the project beside the brief and the register. Then add one line to the project instructions: for voice, follow the brand guide, and compare any draft to its accepted examples before finishing.

Testing the pair on a fresh request

A register and a guide are claims too, in a sense. They claim that drafts written with them will be accurate and on-voice. So test them the way the course tests everything: give Ida real work and inspect the result.

Open a new chat in the Ledgerlane Marketing project. A fresh chat means Ida works from the files and instructions, not from anything said earlier. Ask for a short answer for the website's frequently asked questions page. The request: "Write an answer, under eighty words, to this question from a contractor: I've got two vans. What does it cost and what do I actually get?"

Here is an illustrative version of what comes back. "Two vans is two hundred and sixty pounds a month, including VAT. That covers photographing your receipts, reconciling your bank account every month, preparing your quarterly VAT return, and tax-ready accounts at year end. It doesn't cover payroll, chasing unpaid invoices, or advice on incorporating. Setup takes about two weeks from signing." Below it, as the instructions asked, Ida lists the register rows she used and their checked dates.

Now inspect it in two passes.

Against the register first. Two hundred and sixty pounds matches the two-van row. The four inclusions match their rows. The three exclusions match theirs. "About two weeks from signing" matches the onboarding row, qualifier intact. The footnote lists the rows and the date checked, the twenty-second of September. Then comes "including VAT". Look for a row about whether prices include VAT. There is none. The register says what the price is. It says nothing about tax on that price. Ida has added a claim that sounds routine and has no source.

That is the fault. It is a good example of why the register helps. Without a row-by-row list, "including VAT" reads as ordinary detail and slides past. With the register open, the question is simple: which row is this? No row means no claim.

Against the guide second. Compare the answer to the accepted onboarding email. The sentences are short. Nothing flatters the reader. The exclusions are named. None of the avoided phrases appear. The answer tells the contractor exactly what they would get, which is what the onboarding email does. On voice, it passes.

Record the result in the project, next to the answer: one fault, "stated that the price includes VAT; no register row supports this". Then the revision. Ask Ida to remove the VAT phrase and change nothing else. Read it again. Every claim now maps to a row.

Then do one more thing, because the fault revealed a gap. Contractors will ask about VAT on the price. The register should hold the answer. Add a row for it with its status left open, not current, and assign it to the founder to confirm. Until that row is confirmed, Ida's instructions already tell her not to state it. The test did not just fix one answer. It improved the register every later draft will use.

Save the revised answer and its fault note beside the brief, the register and the guide. The project now holds all three foundations the course set out to build: who the message is for and what it offers, the facts it can state with their dates and owners, and the voice shown through work that passed and failed.

A message you can defend against its evidence has one more test to pass. Can it change shape for one particular customer without breaking? Take a single contractor's situation, such as a penalty letter that arrived last week and one van. The next piece of work is adapting the message to fit that situation while every claim stays tied to its row.

Keeping reference files current across assistants

The register and guide depend on one thing: the assistant reading the files you meant it to read, and applying the rules every time. Two recent changes outside Claude bear on that, and both are worth knowing if you use ChatGPT or Gemini for the same work.

The larger one is at OpenAI. In September 2026 it announced that standalone Custom GPTs will retire on the eleventh of December 2026. Their settings move over to what OpenAI calls Plugins and Skills. The difference matters for a brand guide. A Custom GPT applied its standing instructions on every turn of a conversation. A Skill works differently. ChatGPT calls it up when it judges the Skill relevant to what you asked. Uploaded knowledge files become reference files, and the way they are searched changes too.

For a marketer, the decision this affects is simple to state. If you kept a brand guide and a facts sheet in a Custom GPT, you could count on the voice rules being present every time. After the move, you should not assume that. A request that does not obviously look like brand work might never pull the guide in. The same goes for a price question that Chat­GPT answers from general context without checking the reference file.

The smallest useful action is to run the audit from this chapter after you migrate. Open a fresh chat. Ask it to list every current product fact with its source and date, and to flag disagreements. Then ask for one short piece of copy and check whether the voice rules show up in it. If the list is wrong or the rules are missing, you know before a customer does.

The second change is at Google. Gemini Gems accept up to ten attached files, each up to a hundred megabytes, from Google Drive or your own computer. Reports from monitoring what Gems actually read show silent failures. A complex PDF with several columns, a Word file with an unusual encoding, or a filename with special characters can fail to be read, with no warning. Your Gem looks fully stocked. Part of your register may simply not be there.

The fix is cheap. Keep your register and brand guide as plain text files with clear headings, one section per fact or rule. Give them simple filenames. Then ask the Gem to list what it knows, the same way you would in Claude. A plain file that Gemini can fully read beats a nicely designed PDF that it partly skips.

Across all three assistants, the habit is the same one this chapter built. One current file per job. Old versions out before new ones in. And after any change, a fresh chat that asks the assistant to show you, fact by fact, what it thinks is true.