System: MWMS
Document Type: Protocol
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: AI Business Systems Brain, HeadOffice Brain, Client Brain Systems, AI Manager, AI Employee Router, Brain Room, Offer Brain, Content Brain, Sales Brain, Creative Brain, Future AIBS Client Systems
Parent Page: AI Business Systems Brain
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 Client Brain Intake And Onboarding Protocol.
This protocol establishes how MWMS should onboard a future client, business owner, founder, expert, consultant, coach, agency, service provider, ecommerce brand, or internal business unit before building a client-specific AI Brain or AI Business System.
MWMS must not begin client AI system work by asking:
What do you want AI to do?
That question is too shallow.
The correct starting point is:
What business intelligence must AI understand before it can do useful work for this client?
This protocol exists to ensure that every client Brain starts with disciplined intake, not random prompting.
A client Brain must be built from:
client business context
client offer context
client voice
client methodology
client buyer understanding
client objections
client proof
client workflows
client approval rules
client risk boundaries
client tool permissions
client reporting needs
client outcome goals
Without proper intake, MWMS risks creating client systems that are:
generic
misaligned
unsafe
hard to maintain
too dependent on Martyn
wrong for the client’s buyer
wrong for the client’s offer
wrong for the client’s voice
unclear in responsibility
overbuilt before the offer is understood
unable to scale into future AIBS packages
This protocol turns client onboarding into a governed intelligence intake process.
Scope
This protocol applies to all future MWMS AI Business Systems client builds and any internal MWMS work that follows a client-style Brain creation process.
This includes:
AI Business Systems Brain
HeadOffice Brain
Client Brain systems
Client Context Libraries
Client AI Employees
Client Reporting Systems
Client Asset Systems
Client Workflow Systems
Client Skill Libraries
Client Approval Systems
Offer Brain
Content Brain
Sales Brain
Creative Brain
Conversion Brain
Research Brain
Operations Brain
This protocol applies when MWMS is onboarding:
a new AIBS client
a new client offer
a new client content system
a new client sales system
a new client reporting system
a new client AI Employee
a new client workflow automation concept
a new client knowledge base
a new internal MWMS system that behaves like a client Brain
This protocol does not authorize development work, plugin changes, Supabase changes, WordPress changes, automation wiring, client access setup, credential handling, or M developer action.
Core Definition
Client Brain Intake is the structured process of gathering, classifying, extracting, validating, and organizing the business intelligence needed before creating a client-specific AI system.
Client Brain Onboarding is the process of moving that client from initial discovery into a usable, governed AI context library and operational workflow map.
The intake process determines:
what the client does
who the client serves
what the client sells
how the client delivers value
how the client speaks
what the client believes
what the client’s buyers need
what the client’s buyers resist
what proof the client can use
what systems the client already has
what AI should and should not do
what humans must still approve
what risks must be controlled
what outcomes matter
Core Principle
The core principle of this protocol is:
A client AI system should not be built until the client’s business context, offer context, voice, workflows, and approval boundaries are understood.
AIBS is not prompt installation.
AIBS is business intelligence structuring.
MWMS must build client AI systems from governed context, not from generic AI enthusiasm.
Client Intake Stages
MWMS Client Brain Intake uses seven stages.
Stage 1: Client Fit And Scope Check
Stage 2: Business Context Intake
Stage 3: Offer And Buyer Intake
Stage 4: IP Excavation
Stage 5: Context Library Construction
Stage 6: Workflow And Skill Mapping
Stage 7: Activation Readiness Review
Each stage must produce usable output before the next stage becomes operational.
Stage 1: Client Fit And Scope Check
Purpose
The purpose of this stage is to determine whether the client is suitable for a MWMS AI Business System and what type of system should be considered.
MWMS should not accept every possible client into a full AI Brain build.
Some clients may need:
strategy first
offer clarification first
workflow cleanup first
basic documentation first
manual service first
simple prompt support first
no action
Fit Questions
Ask:
What type of business is this?
What does the client sell?
Who is the buyer?
Is the offer clear?
Is there existing source material?
Does the business have repeatable workflows?
Does the client understand their buyer?
Is there proof or customer data?
Does the client have unrealistic expectations?
Does the client need AI, or do they need business clarity first?
Is the client prepared to review and approve outputs?
Does the client have compliance risks?
Does the client expect automation before process clarity?
Output
This stage should produce:
Client Fit Decision
Initial Scope
Primary Business Goal
Primary System Need
Risk Notes
Recommended Starting Point
Possible Outcomes
Proceed To Intake
Strategy Clarification First
Offer Clarification First
Workflow Cleanup First
Not Suitable Yet
Park For Later
Reject
Stage 2: Business Context Intake
Purpose
The purpose of this stage is to understand the client’s business at a high level.
This stage captures the client’s business model, positioning, operations, priorities, constraints, and current systems.
Business Context Questions
Ask:
What does the business do?
Who does it serve?
What are the main revenue streams?
What is the current business model?
What is the main growth goal?
What is the main operational pain?
What currently takes too much time?
What work repeats every week?
What work depends too heavily on the owner?
What systems already exist?
What tools are currently used?
What should AI never touch?
What must remain human-approved?
Output
This stage should produce:
Client Business Snapshot
Current Business Model
Primary Business Goal
Current Constraints
Main Repeating Workflows
Current Tool Stack
Current Bottlenecks
Initial AI Opportunity Areas
Human Approval Boundaries
Stage 3: Offer And Buyer Intake
Purpose
The purpose of this stage is to understand the client’s main offer and buyer.
A client Brain should usually begin with one offer.
Trying to build AI context around the entire business at once can create vague output.
Offer Questions
Ask:
What is the primary offer?
What problem does it solve?
Who is the offer for?
What is included?
How is it delivered?
What is the price or pricing model if relevant?
What result does the client promise?
What result should not be promised?
What makes this offer different?
What proof exists?
What objections appear most often?
What happens after someone buys?
Buyer Questions
Ask:
Who is the best-fit buyer?
What situation are they in before buying?
What do they already believe?
What are they afraid of?
What have they tried before?
What do they want practically?
What do they want emotionally?
What makes them hesitate?
What makes them trust?
What language do they use?
Output
This stage should produce:
Primary Offer Selection
Initial Offer Profile
Initial Buyer Profile
Core Transformation
Known Objections
Known Proof
Known Buyer Language
Offer Risk Notes
Stage 4: IP Excavation
Purpose
The purpose of this stage is to extract the client’s deeper business intelligence.
This includes the beliefs, methodology, and expert thinking that make the client’s work distinct.
This stage uses the MWMS Client IP Excavation Framework.
Primary Outputs
Create:
My Contrarian Stances
My Methodology
My Expert Thinking
Additional Outputs Where Available
Customer Language Extract
Objection Extract
Proof Extract
Voice Notes
Retired Language Candidates
Missing Evidence List
Rules
Extract only what is present.
Do not invent client beliefs.
Do not invent methodology.
Do not invent proof.
Do not invent customer language.
Flag missing material clearly.
Preserve useful real language.
Output
This stage should produce approved or review-ready IP Excavation files.
Stage 5: Context Library Construction
Purpose
The purpose of this stage is to convert client intelligence into a structured client context library.
This stage uses the MWMS Offer Context Library Standard.
Client Context Library Files
Where relevant, create:
Right-Fit Client Profile
Offer Profile
Voice Architecture
Differentiation Profile
Objection Library
Methodology Map
Expert Thinking Rules
Customer Language Bank
Proof Library
Brand Visual Style
Retired Language
Compliance Notes
Client Approval Rules
Client Reporting Preferences
Tool Stack Notes
Workflow Constraints
Rules
Client context must remain isolated.
Draft files must be marked.
Approved files must be clear.
Client source truth must not be mixed with MWMS internal context.
Client proof must not be invented.
Client voice must be preserved.
Output
This stage should produce a draft or approved Client Context Library.
Stage 6: Workflow And Skill Mapping
Purpose
The purpose of this stage is to identify which client workflows may become AI-assisted skills or AI Employee tasks.
Not every client task should become an AI workflow.
MWMS must identify repeatable, valuable, bounded work.
Workflow Mapping Questions
Ask:
What tasks repeat weekly?
What tasks repeat monthly?
What tasks require the client’s judgment?
What tasks are currently slow?
What tasks are currently inconsistent?
What tasks have a clear procedure?
What tasks have a clear output?
What tasks require human review?
What tasks involve sensitive data?
What tasks should not be automated?
What work could become a skill?
What work should remain manual?
Skill Candidate Test
A client workflow may become a skill if:
the task repeats
the process is known
the output can be defined
the context exists
the risk is manageable
human review can be applied
the work creates business value
Possible Client Skill Candidates
Content Brief Skill
Newsletter Drafting Skill
Sales Follow-Up Skill
Client Report Drafting Skill
Lead Magnet Builder Skill
Objection Handling Skill
Voice Checker Skill
Customer Support Reply Skill
Proposal Drafting Skill
Meeting Summary Skill
Workflow Summary Skill
Output
This stage should produce:
Client Workflow Map
Skill Candidate List
Manual Workflow List
Human Review Requirements
Risk Notes
Priority Skill Recommendations
Stage 7: Activation Readiness Review
Purpose
The purpose of this stage is to determine whether the client Brain is ready to be used in real AI work.
Activation readiness protects MWMS from using incomplete client context too early.
Readiness Questions
Ask:
Is the primary offer clear?
Is the best-fit buyer clear?
Is the voice clear?
Is the methodology clear?
Are objections captured?
Is approved proof available?
Are retired language rules defined?
Are client approval boundaries clear?
Are tool permissions clear?
Are workflow candidates identified?
Are high-risk areas flagged?
Are context files marked draft or approved?
Does the client understand review requirements?
Output
This stage should produce one of the following decisions:
Ready For Manual Use
Ready For Assisted Use
Needs More Context
Needs Client Review
Needs Offer Clarification
Needs Workflow Clarification
Park For Later
Not Ready
Client Intake Source Material
MWMS should collect useful source material during onboarding.
Recommended source material includes:
website pages
sales pages
landing pages
emails
newsletters
social posts
offer documents
proposals
SOPs
client onboarding docs
brand guides
testimonials
case studies
customer reviews
sales call notes
FAQ documents
support messages
customer survey results
training material
workshop material
voice memos
Loom reviews
previous AI prompts
tool stack list
workflow notes
report examples
approval rules
The client should not be required to polish this material before sharing it.
Raw material is useful because it reveals real language and real operations.
Client Intake Modes
MWMS supports two client intake modes.
Guided Intake Mode
Used when the client needs help answering questions.
The AI or human interviewer asks one question at a time.
Best for:
less documented clients
early-stage offers
founders who think by talking
messy business models
new service packages
Source Review Mode
Used when the client has existing material.
The AI reads and extracts intelligence from provided files.
Best for:
established businesses
course creators
agencies
brands with sales assets
consultants with content archives
ecommerce brands with customer reviews
Hybrid Intake Mode
Used when some source material exists but gaps remain.
This is likely the most common future AIBS mode.
Client Boundary Rules
Rule 1: One Client At A Time
Client context must not be mixed.
Rule 2: One Primary Offer First
Start with one offer unless the client has a clear multi-offer structure.
Rule 3: Draft Is Not Approved
Client draft context must not be treated as active source truth.
Rule 4: Human Review Required
Client context must be reviewed before use in important outputs.
Rule 5: Sensitive Data Must Be Limited
Do not include unnecessary personal, financial, credential, or confidential material.
Rule 6: Tool Access Does Not Come From Intake
Tool access must be permissioned separately.
Rule 7: Automation Comes After Manual Clarity
Do not automate a workflow before the process is understood.
Rule 8: Client Context Must Remain Isolated
No client context may leak into another client system or MWMS general context.
Client Intake Quality Standards
A strong client intake should be:
specific
source-grounded
offer-focused
buyer-aware
voice-aware
workflow-aware
risk-aware
review-ready
easy to convert into context files
A weak client intake is:
generic
too broad
missing offer clarity
missing buyer clarity
missing voice
missing proof
missing workflow boundaries
filled with assumptions
not tied to business outcomes
Client Intake Failure Modes
MWMS must prevent:
starting with tools instead of business context
building around the whole business too early
accepting vague offer descriptions
inventing missing client strategy
ignoring approval boundaries
mixing client context with MWMS context
moving to automation too early
creating skills without repeatable workflows
using proof that has not been approved
allowing old client files to remain active
building public-facing output before review
Client Brain Output Package
A completed client intake may produce:
Client Business Snapshot
Primary Offer Profile
Right-Fit Client Profile
Client Voice Architecture
Differentiation Profile
Objection Library
Methodology Map
Expert Thinking Rules
Customer Language Bank
Proof Library
Retired Language
Compliance Notes
Client Workflow Map
Skill Candidate List
Human Review Rules
Activation Readiness Decision
Not every client will need every file at the start.
But full client Brain builds should move toward a complete package over time.
Relationship To Client Delivery
This protocol supports future AIBS delivery.
Client Brain Intake may become the first stage of a paid client package.
Possible package stages:
Discovery
IP Excavation
Context Library Build
Skill Mapping
Manual Use Setup
Client Review
First Asset Build
Audit Schedule
This supports recurring value because the client Brain can be maintained, updated, audited, and improved over time.
Governance Role
AI Business Systems Brain owns the MWMS Client Brain Intake And Onboarding Protocol.
HeadOffice governs cross-system standards, risk, source-of-truth discipline, and review requirements.
AI Business Systems Brain is responsible for:
client intake structure
client Brain packaging
client library requirements
client workflow mapping
client skill candidate review
client activation readiness
client isolation rules
future client delivery model alignment
HeadOffice is responsible for:
governance alignment
risk escalation
MCR source-of-truth protection
privacy and context boundary oversight
human review requirements
cross-Brain coordination
Relationship To Other MWMS Standards
This protocol supports and must align with:
MWMS Document Structure Standard
MWMS AI Brain Build Sequence Framework
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 Context-Driven Asset Builder Framework
MWMS AI Skill Builder And Audit Protocol
MWMS AI Brain Audit And Decay Prevention Framework
MWMS Tool-Agnostic Context Portability Protocol
MWMS AI Agent Memory And Context Framework
MWMS AI Agent Skill Library Framework
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS Brain Routing Rule
MWMS MCR Promotion To Brain Protocol
MWMS Page Naming Standard
MWMS Architecture Registry
AI Business Systems Brain Canon
Offer Brain Offer Structure Framework
Content Brain VOC Grounded AI Copy Framework
Sales Brain Conversation Structure Framework
Compliance Brain Claims Risk Framework
This protocol converts the context-building standards into a future client onboarding process.
Drift Protection
This protocol protects MWMS from:
starting client work with shallow prompts
building AI systems before business context is clear
tool-first client onboarding
generic client systems
unclear offer context
unclear buyer context
missing approval boundaries
client context leakage
automation before workflow clarity
client proof invention
client voice drift
client libraries becoming mixed with MWMS libraries
client Brain activation before readiness
future AIBS systems becoming overbuilt or unsafe
Any client Brain created without structured intake should be treated as a drift risk.
Architectural Intent
The architectural intent of the MWMS Client Brain Intake And Onboarding Protocol is to make future AIBS client delivery structured, repeatable, safe, and scalable.
MWMS must not sell AI systems as random prompt packs.
MWMS must build client systems from governed business intelligence.
The long-term goal is that every future AIBS client onboarding can answer:
Who is this client?
What do they sell?
Who do they serve?
What is the primary offer?
What does the buyer believe?
What does the client believe?
How does the client create transformation?
What proof is approved?
What voice should AI preserve?
What workflows repeat?
What should AI never touch?
What requires human review?
What is ready now?
What must be clarified first?
When MWMS can answer these questions consistently, client AI systems become more useful, safer, easier to maintain, and easier to package into recurring AIBS revenue.
Change Log
v1.0 — Initial Draft
Created the MWMS Client Brain Intake And Onboarding Protocol as the structured future AIBS client onboarding process for gathering business context, offer context, buyer context, IP, voice, proof, workflows, skills, approval boundaries, and activation readiness before building client-specific AI systems.
This protocol defines the seven-stage intake process, intake source material, intake modes, client boundary rules, quality standards, failure modes, output package, relationship to client delivery, governance role, drift protection, and architectural intent.
Change Impact Declaration
Pages Created:
MWMS Client Brain Intake And Onboarding Protocol
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
AI Business Systems Brain Page Registry
HeadOffice Page Registry
Offer Brain Page Registry
Content Brain Page Registry
Sales Brain Page Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes
Employee Impact Check
Employees impacted:
AI Business Systems Architect Employee
HeadOffice Manager Employee
Client IP Excavator
Context Library Builder
Offer Strategist Employee
Content Planner Employee
Sales Strategist Employee
Creative Strategist Employee
Research Analyst Employee
AI Manager
AI Employee Router
Required behaviour updates:
AI Employees must not begin future client Brain work by jumping directly into prompts, tools, automations, or asset creation.
AI Employees must first gather business context, offer context, buyer context, client IP, workflow context, approval boundaries, and risk constraints.
AI Employees must treat client context as isolated and must not mix client libraries with MWMS internal context or other client systems.
AI Employees must identify whether a client is ready for manual use, assisted use, more context, client review, offer clarification, workflow clarification, parking, or rejection.
AI Employees must map repeatable client workflows into skill candidates only after the workflow is understood and risk boundaries are clear.
END MWMS CLIENT BRAIN INTAKE AND ONBOARDING PROTOCOL v1.0