MWMS Voice Architecture And Brand Language Standard

System: MWMS
Document Type: Standard
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AI Business Systems Brain, Content Brain, Offer Brain, Creative Brain, Sales Brain, Conversion Brain, Customer Brain, AI Manager, AI Employee Router, Future AIBS Client Systems
Parent Page: Content Brain Canon
Owner: Martyn
Developer Boundary: No Development Action Authorized By This Page
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS Voice Architecture And Brand Language Standard.

This standard establishes how MWMS captures, structures, governs, preserves, reviews, and applies founder voice, brand voice, offer language, customer language, preferred phrasing, banned wording, retired language, tone rules, and communication style across AI-generated business outputs.

MWMS must not allow AI-generated content to sound generic.

AI output should not become:

over-polished

corporate

robotic

bland

too perfect

too safe

too vague

too distant from the founder

too detached from the buyer

too similar across different clients or offers

Voice is not decoration.

Voice is part of trust.

Voice helps the buyer feel that the business is real, specific, consistent, and credible.

This standard exists because AI tools often flatten voice unless the system gives them clear structure.

The Voice Architecture And Brand Language Standard gives MWMS a way to preserve voice across:

content

emails

ads

VEO3 scripts

landing pages

webinars

lead magnets

sales scripts

client reports

AI Employee outputs

future AIBS client systems

Scope

This standard applies to all MWMS work where AI creates, reviews, rewrites, adapts, or evaluates language intended for humans.

This includes:

Content Brain

Offer Brain

Creative Brain

Sales Brain

Conversion Brain

Customer Brain

Research Brain

Affiliate Brain

Ads Brain

AI Business Systems Brain

HeadOffice Brain

AI Manager

AI Employee Router

Course Absorption System

Client Brain systems

future AIBS client systems

This standard applies to:

emails

newsletters

landing pages

sales pages

VSL scripts

VEO3 scripts

ad scripts

social posts

lead magnets

webinars

client reports

onboarding messages

support replies

brand documents

offer pages

internal AI Employee output

client-facing AI output

This standard does not authorize development work, plugin changes, Supabase changes, WordPress changes, automation wiring, publishing, client implementation, or M developer action.

Core Definition

Voice Architecture is the structured context file that defines how a founder, business, offer, brand, Brain, or client should sound.

Brand Language is the set of words, phrases, tones, expressions, examples, exclusions, and communication habits that make that voice recognizable and consistent.

Voice Architecture may include:

tone

rhythm

sentence style

directness level

humour level

formality level

emotional register

preferred phrases

banned phrases

retired language

example openings

example CTAs

founder expressions

customer-facing phrasing

words to avoid

words to preserve

before-and-after examples

Voice Architecture is not a generic tone guide.

It is a working source file that AI Employees must read before creating or reviewing language-heavy outputs.

Core Principle

The core principle of this standard is:

AI should preserve the real communication style of the business, not replace it with generic marketing language.

AI may improve clarity.

AI may improve structure.

AI may improve flow.

AI may improve conversion logic.

But AI must not erase the voice that makes the business specific.

Voice should be governed, not guessed.

Voice Architecture File

Each serious offer, Brain, founder, brand, or client system should have a Voice Architecture file where voice matters.

The file should define:

Voice Summary

Tone Rules

Rhythm And Sentence Style

Preferred Language

Banned Language

Retired Language

Founder Phrases

Customer Language Usage

CTA Style

Humour And Personality Rules

Emotional Register

Examples Of Strong Voice

Examples Of Weak Voice

Platform Adjustments

Compliance And Claim Language Notes

The Voice Architecture file should sit inside the approved context library.

It should not be scattered across random prompts, chat history, or project notes.

Voice Summary

Purpose

The Voice Summary gives a short overview of how the brand or founder should sound.

Examples:

direct but warm

plainspoken and practical

confident but not arrogant

expert but not academic

humorous but not silly

premium but not corporate

sharp but not aggressive

calm but not passive

The Voice Summary helps AI Employees quickly understand the overall feel.

Tone Rules

Tone Rules define what emotional and communication style should be used.

Tone may include:

friendly

direct

curious

bold

practical

reassuring

strategic

challenging

plainspoken

energetic

calm

premium

conversational

Tone Rules should also define what the voice is not.

Examples:

not hype-heavy

not robotic

not corporate

not overly academic

not fluffy

not fake urgent

not overly polished

not childish

not fearmongering

Rhythm And Sentence Style

Rhythm defines how the writing moves.

It may include:

short sentences

varied sentence length

simple structure

punchy lines

clear spacing

plain language

occasional fragments

strong transitions

low jargon

direct calls to action

AI often creates long, smooth paragraphs.

MWMS should preserve rhythm where rhythm matters.

Preferred Language

Preferred Language includes words, phrases, and expressions that should be used where appropriate.

Examples:

plain words

founder phrases

brand phrases

buyer-recognizable language

offer-specific terms

framework names

approved terminology

category language

Preferred language should be specific enough to guide AI, but not so rigid that every output sounds repeated.

Banned Language

Banned Language includes words and phrases that should not be used.

Examples:

generic hype

overused AI phrases

empty marketing language

unapproved claims

phrases the founder dislikes

language that sounds off-brand

phrases that create compliance risk

Examples of common banned AI-style phrases may include:

unlock your potential

game-changing

revolutionary

seamless solution

in today’s fast-paced world

take your business to the next level

supercharge your success

unless the specific brand truly uses that language.

Retired Language

Retired Language includes words, phrases, claims, taglines, old positioning, old campaign language, or old offer descriptions that used to be used but should no longer appear.

Retired Language is active protection.

It tells AI what not to resurrect.

Retired Language may include:

old slogans

outdated claims

old offer names

old pricing references

old campaign angles

old compliance-sensitive wording

old product descriptions

old brand positioning

phrases that caused ad disapproval

phrases that no longer match strategy

Retired Language must be checked for public-facing and customer-facing outputs.

Founder Phrases

Founder Phrases are real phrases the founder, business owner, expert, or brand naturally uses.

These may come from:

emails

voice notes

calls

training videos

course content

social posts

sales calls

interviews

Brain Room messages

old scripts

Founder Phrases help AI preserve human voice.

MWMS should preserve strong founder language where useful.

Do not over-polish founder phrases until they lose personality.

Customer Language Usage

Customer Language is different from founder voice.

Customer language reflects how buyers describe problems, desires, anxieties, objections, and outcomes.

Voice Architecture should define how customer language should be used.

Rules:

use customer language for resonance

do not pretend customer language is founder voice

do not invent customer quotes

do not exaggerate emotional language

do not distort buyer wording

preserve strong real phrases where useful

Customer Language should connect with the Content Brain VOC Grounded AI Copy Framework.

CTA Style

CTA Style defines how the brand asks people to take action.

CTA style may be:

direct

soft

curious

instructional

minimal

urgent

calm

educational

playful

premium

Examples:

Watch the video now.

See how it works.

Start with the checklist.

Book your review.

Get the guide.

Compare your options.

CTAs should match the brand voice and buyer readiness.

Do not use aggressive CTAs if the brand voice is calm and advisory.

Do not use soft CTAs if the campaign requires direct-response clarity.

Humour And Personality Rules

Some brands use humour.

Some do not.

Voice Architecture should define:

whether humour is allowed

what type of humour fits

what humour is off-limits

how playful the brand can be

whether sarcasm is allowed

whether self-deprecation is allowed

whether jokes should be avoided in serious contexts

For MWMS, humour may be useful in some ad concepts, VEO3 hooks, and content, but it must not damage trust, compliance, or offer clarity.

Emotional Register

Emotional Register defines the emotional level the voice should use.

Examples:

calm and reassuring

urgent but not fearful

bold but not aggressive

empathetic but not sentimental

serious but not cold

curious but not vague

Emotional Register helps prevent AI from either underplaying or overdramatizing the message.

For affiliate, health, finance, compliance-sensitive, or paid traffic outputs, emotional register must be checked carefully.

Examples Of Strong Voice

The Voice Architecture file should include strong examples.

Examples may include:

headline examples

email openings

CTA examples

paragraph examples

story snippets

founder phrases

ad hook examples

before-and-after rewrites

Strong examples help AI match style more accurately.

Examples Of Weak Voice

The Voice Architecture file should also include examples of what not to do.

Examples may include:

too corporate

too robotic

too hype-heavy

too academic

too vague

too polished

too salesy

too casual

too childish

too fear-based

Weak examples are useful because AI often needs contrast.

Platform Adjustments

Voice may shift slightly by platform.

Examples:

YouTube ad scripts may be punchier.

Emails may be warmer.

MCR pages must be operational and governed.

Client reports may be clearer and more formal.

Social posts may be more conversational.

Landing pages may be more direct-response focused.

Voice Architecture should define permitted platform adjustments without losing the core voice.

Compliance And Claim Language Notes

Some voice choices create risk.

Voice Architecture should include claim language notes where relevant.

Examples:

avoid guaranteed outcomes

avoid medical claims

avoid income promises

avoid exaggerated fear

avoid fake scarcity

avoid unsupported proof

avoid misleading testimonial language

avoid direct product claims not approved by vendor

Compliance Brain should review claim-sensitive voice rules where necessary.

Voice Extraction Sources

MWMS may extract voice from:

emails

newsletters

social posts

video transcripts

sales pages

podcasts

voice memos

workshop recordings

Brain Room chats

client reports

founder notes

customer replies

sales calls

course content

The best voice sources are usually real, natural, and unpolished.

Highly polished marketing pages can help, but they may not capture the founder’s real voice.

Voice Extraction Workflow

MWMS uses the following workflow.

Step 1: Gather Voice Samples

Collect writing and speaking samples.

Step 2: Separate Founder Voice From Customer Language

Founder voice and customer wording serve different roles.

Step 3: Identify Repeated Patterns

Look for repeated tone, phrasing, rhythm, transitions, CTAs, humour, and emotional style.

Step 4: Identify Strong Phrases

Capture phrases that feel specific and usable.

Step 5: Identify Weak Or Unwanted Language

Capture language that should not be repeated.

Step 6: Identify Retired Language

Mark old positioning, old phrases, and outdated claims.

Step 7: Create Voice Architecture File

Structure findings into the approved format.

Step 8: Review With Human Operator

Voice requires human review because it is subjective and brand-sensitive.

Step 9: Activate For Use

Once approved, the file becomes part of the active context library.

Voice Usage Rules

Rule 1: Voice Must Be Based On Evidence

Do not invent brand voice from a few vague adjectives.

Rule 2: Voice Must Be Separated From Buyer Language

The buyer’s words are not automatically the brand’s voice.

Rule 3: Retired Language Must Be Enforced

Old language must not reappear in new outputs.

Rule 4: AI May Clarify But Must Not Flatten

AI may improve readability without making the copy generic.

Rule 5: Voice Must Serve The Asset Objective

Voice should support the purpose of the asset.

Rule 6: Compliance Overrides Voice

If brand voice creates compliance risk, compliance wins.

Rule 7: Human Review Is Required For Voice Approval

AI can draft voice rules, but human review must approve them.

Rule 8: Client Voice Must Stay Isolated

Client voice files must not influence other clients or MWMS internal voice.

Voice Validation Checklist

Before approving a language-heavy output, check:

Does it sound like the approved voice?

Is it too generic?

Is it over-polished?

Is it too corporate?

Is it too casual?

Is it too hype-heavy?

Is rhythm consistent?

Are preferred phrases used where appropriate?

Are banned phrases avoided?

Is retired language avoided?

Is customer language used accurately?

Are claims safe?

Is the CTA style aligned?

Does the platform adjustment make sense?

Would the founder or client actually say this?

If the answer is no, revise before use.

Voice Drift Signals

Voice may be drifting if:

outputs sound like generic AI

the same phrases appear repeatedly

the founder keeps rewriting tone

customer-facing copy feels off

old phrases return

CTAs feel wrong

emails sound unlike the brand

ads sound too hype-heavy

reports sound too robotic

social posts sound too polished

client feedback says “this does not sound like us”

Repeated voice correction should trigger a Voice Architecture review.

Rewrite Versus Polish Rule

If the human reviewer only polishes small wording, voice may be acceptable.

If the human reviewer rewrites the whole tone, rhythm, structure, or phrasing, the Voice Architecture needs review.

Small edits are normal.

Repeated full rewrites signal voice decay.

Application To MWMS Internal Voice

MWMS internal documents must use operational clarity.

MCR pages should be:

structured

plain

direct

governed

not fluffy

not academic

not salesy

not chatty

not filled with course references

not filled with citations inside the page output

MWMS internal voice should support AI interpretation and governance.

Application To Content Brain

Content Brain uses Voice Architecture to create:

emails

social posts

newsletters

content briefs

headlines

hooks

educational content

belief-shift content

Content Brain must use VOC and Voice Architecture together.

VOC grounds the buyer reality.

Voice Architecture preserves the brand expression.

Application To Creative Brain

Creative Brain uses Voice Architecture to create:

ad hooks

VEO3 scripts

storyboards

thumbnail text

campaign concepts

visual prompt language

Creative Brain may stretch style for creative testing but must not violate approved voice, retired language, or compliance notes.

Application To Sales Brain

Sales Brain uses Voice Architecture to create:

sales scripts

follow-up messages

objection responses

proposal language

call summaries

sales emails

Sales Brain must preserve trust and avoid over-hype.

Application To AIBS Client Systems

Future AIBS client systems require client-specific Voice Architecture files.

Client voice must be isolated.

A client Voice Architecture should include:

client tone

client phrases

client banned phrases

client CTA style

client examples

client retired language

client compliance notes

client approval rules

Client voice must not leak into MWMS internal voice or another client system.

Common Failure Modes

MWMS must prevent:

AI-generated generic voice

over-polishing founder language

mixing founder voice with buyer language

using old campaign language

using retired phrases

inventing customer wording

using compliance-risky claims for the sake of punchiness

making every client sound the same

making MCR pages sound like marketing pages

using voice files without human review

allowing voice examples to become stale

Governance Role

Content Brain owns the MWMS Voice Architecture And Brand Language Standard.

HeadOffice governs cross-Brain alignment, MCR voice discipline, and source-of-truth usage.

Offer Brain governs offer-specific language.

Creative Brain governs creative expression within voice boundaries.

Sales Brain governs sales language.

Conversion Brain governs conversion copy alignment.

Compliance Brain governs claim-sensitive language.

AI Business Systems Brain governs future client voice architecture usage.

Individual Brains may define specialized voice usage, but they must align with this standard.

Relationship To Other MWMS Standards

This standard supports and must align with:

MWMS Document Structure Standard

MWMS Client IP Excavation Framework

MWMS Offer Context Library Standard

MWMS Context Library Governance And Folder Map Standard

MWMS AI Context Activation And Usage Protocol

MWMS AI Context Pack Template Standard

MWMS Context-Driven Asset Builder Framework

MWMS Content Intelligence Scanner Framework

MWMS AI Brain Audit And Decay Prevention Framework

MWMS AI Brain Readiness Review Checklist

MWMS Tool-Agnostic Context Portability Protocol

Content Brain VOC Grounded AI Copy Framework

Research Brain Voice Of Customer Extraction Framework

Creative Brain Belief Shift Framework

Sales Brain Objection Resolution Framework

Conversion Brain Landing Page Structure Framework

Compliance Brain Claims Risk Framework

AI Business Systems Brain Canon

This standard provides the voice and language governance layer for context-driven AI output.

Drift Protection

This standard protects MWMS from:

generic AI copy

voice flattening

over-polished language

old language returning

banned phrases reappearing

founder voice being replaced

client voices blending together

buyer language being invented

MCR pages becoming sales copy

public-facing claims becoming unsafe

AI Employees ignoring voice context

client systems producing off-brand output

Any language-heavy AI output produced without relevant Voice Architecture should be treated as a voice drift risk.

Architectural Intent

The architectural intent of the MWMS Voice Architecture And Brand Language Standard is to make voice reusable, governable, and portable across MWMS AI systems.

MWMS needs AI outputs that are not only correct, but recognizably aligned with the business, offer, founder, client, and buyer.

The long-term goal is that every serious brand or offer can answer:

How should this sound?

What should it never sound like?

What phrases should be preserved?

What phrases are banned?

What language has been retired?

How should CTAs sound?

How should humour be used?

How should emotion be handled?

What examples show the voice correctly?

What examples show the voice incorrectly?

When MWMS can answer these questions consistently, AI-generated content becomes more specific, more trusted, more brand-aligned, and safer to scale.

Change Log

v1.0 — Initial Draft

Created the MWMS Voice Architecture And Brand Language Standard as the standard for capturing, structuring, preserving, reviewing, and applying founder voice, brand voice, offer language, customer language, preferred phrasing, banned wording, retired language, tone rules, and communication style across MWMS AI-generated outputs and future AIBS client systems.

This standard defines Voice Architecture, Brand Language, voice file structure, tone rules, rhythm, preferred language, banned language, retired language, founder phrases, customer language usage, CTA style, humour rules, emotional register, platform adjustments, extraction workflow, usage rules, validation checklist, drift signals, Brain applications, governance role, drift protection, and architectural intent.

Change Impact Declaration

Pages Created:

MWMS Voice Architecture And Brand Language Standard

Pages Updated:

None

Pages Deprecated:

None

Registries Requiring Update:

MWMS Architecture Registry

Content Brain Page Registry

Offer Brain Page Registry

Creative Brain Page Registry

Sales Brain Page Registry

AI Business Systems Brain Page Registry

Canon Version Update Required:

No

Change Log Entry Required:

Yes

Employee Impact Check

Employees impacted:

Content Planner Employee

Creative Strategist Employee

Sales Strategist Employee

Conversion Strategist Employee

Offer Strategist Employee

Context Library Builder

Client IP Excavator

AI Business Systems Architect Employee

HeadOffice Manager Employee

Required behaviour updates:

AI Employees must use approved Voice Architecture when creating or reviewing language-heavy outputs.

AI Employees must not flatten founder or client voice into generic AI marketing language.

AI Employees must preserve useful founder phrasing where appropriate and avoid banned or retired language.

AI Employees must separate founder voice from customer language and must not invent customer wording.

AI Employees must route repeated voice rewrites, voice mismatch, or retired language recurrence into voice audit or context library refresh.

END MWMS VOICE ARCHITECTURE AND BRAND LANGUAGE STANDARD v1.0