Say you write blog content for three clients under one brand-voice service, each paying for content that's supposed to sound like their brand and nobody else's. Each client is supposed to sound distinct and consistent from post to post, and if you're holding that consistency in your head instead of in a written rule, it drifts: a phrase you'd banned for Client A creeps into Client B's post, a formatting habit from your own writing shows up where the client's guide says otherwise. Not because you're careless, but because "how Client B sounds" isn't the kind of thing memory reliably holds constant across forty posts written over six months.
Brand-voice consistency is a rules problem, not a talent problem
The instinct is to treat inconsistent brand voice as a writing-skill issue: try harder to remember the style, reread old posts before starting a new one. That works for a while and breaks down as the client list grows, because the thing being asked isn't "write well," it's "hold five or six different rule sets in your head at once and never let them blur," which is a different and much harder task than writing any single post well. Turning tone into an explicit, written rule set fixes the actual problem: consistency stops depending on memory.
Two global blocks: tone rules and formatting rules
In PAL, that rule set becomes two global Blends: Tone & Voice Rules (how the writing should sound, what vocabulary is off-limits, sentence-length habits) and Formatting Rules (heading structure, how long a post runs, how sources get cited). Both live at global scope, so every client's content generator can reference them. Write the rule once here instead of re-explaining it in a client-specific brief every time you sit down to write.
The client voice profile: what's actually client-specific
What's genuinely different per client is smaller than it feels: a name, an industry, an audience, maybe a target word count. That's what a {{client}} Voice Profile block holds, using variables like {{client}}, {{topic}}, {{audience}}, and {{word_count}}. It's the one piece of this system that changes for every client, and it stays short because everything that would otherwise repeat across profiles already lives in the two global blocks.
Chaining it into one generator block
A Blog Post Generator Blend ties the three pieces together: it references Tone & Voice Rules, Formatting Rules, and the current client's Voice Profile, composing all three into one finished piece at generation time, which PAL calls Brewing. Fill in the Voice Profile's variables for the client you're writing for, generate, and PAL renders one piece of text built from rules that live in exactly three places, not scattered across a folder of separate client briefs.
Adding a fourth client without rebuilding the system
Bringing on a new client means writing one new Voice Profile, not touching the two global blocks or the generator that ties them together. You fill in a client name, a short description of their audience, and whatever tone notes actually differ from your default, a stricter no-jokes rule, a specific reading level, an industry vocabulary list, then point the same Blog Post Generator at that profile instead of building a fourth version of the whole prompt from nothing. The work of onboarding scales with what's actually different about the client, not with how many clients came before them.
Fix tone drift once, everywhere it's used
When a tone rule stops working, a piece of jargon creeps back in, a sentence pattern reads too stiff, you fix it in Tone & Voice Rules, and every client's generator picks up the change the next time you generate from it. Say a client's style guide gets updated to drop a phrase you'd been using in every post, or an editor points out your sentences have been running long for weeks without anyone flagging it. Either way, the fix lives in Tone & Voice Rules, written once, and it reaches every client's Blog Post Generator on the next generation, not just the one post that prompted the fix. Already-generated posts stay exactly as they were written; PAL's generation history keeps an append-only record of what you actually brewed for each client, useful for checking what already went out, not for rewriting it after the fact. As the client list grows, PAL's library search, filters, and favorites keep that many generator Blends and Voice Profiles findable instead of turning into their own version of the folder problem.
What this doesn't do
PAL doesn't check whether a generated post actually matches the voice rules, and it doesn't publish anything on its own. A human still reads every generation before it goes out, same as before. What's different is that the rules that human is checking against are written down in one place instead of remembered differently by whoever's writing that day. That's a deliberate boundary: PAL assembles the prompt from rules you wrote, it doesn't read the output back and judge it against them.
If you haven't built the underlying Project and Blend structure this pattern assumes, What Is a Reusable Prompt System covers that ground first. To see the actual blocks behind this example, tone rules, formatting rules, and a client voice profile feeding one generator, open the client brand-voice system in the gallery and look at how the three pieces actually reference each other, rather than taking the description above on faith.