MWMS Client Context Isolation And Privacy Boundary Standard

System: MWMS
Document Type: Standard
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: AI Business Systems Brain, HeadOffice Brain, AI Manager, AI Employee Router, Brain Room, Client Brain Systems, Offer Brain, Content Brain, Sales Brain, Creative Brain, Research Brain, Compliance 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 Context Isolation And Privacy Boundary Standard.

This standard establishes how MWMS separates, protects, scopes, reviews, and governs client-specific context inside future AI Business Systems, client Brain builds, client libraries, client skills, client reports, client proof files, client voice files, and client workflow systems.

MWMS must not allow client context to leak across systems.

A future AIBS client system may contain sensitive or business-specific material such as:

client offer details

client buyer profiles

client proof

client testimonials

client voice

client sales process

client workflows

client strategy

client customer language

client internal operations

client reports

client approval rules

client tool notes

client performance data

client private documents

This material must stay inside the correct client boundary.

Without this standard, MWMS risks:

mixing client context

using one client’s proof for another client

reusing one client’s voice elsewhere

allowing client-specific skills to influence general MWMS outputs

turning private client workflows into general templates without approval

creating client reports from wrong context

exposing private business information

weakening trust in future AIBS delivery

Client context isolation is not optional.

It is a core trust, governance, and future delivery requirement.

Scope

This standard applies to all future MWMS client-specific AI systems, client context libraries, client skill systems, client assets, client reports, client workflows, and AI Business Systems delivery packages.

This includes:

AI Business Systems Brain

HeadOffice Brain

AI Manager

AI Employee Router

Brain Room

Client Brain systems

Client Context Libraries

Client Skill Libraries

Client Reporting Systems

Client Workflow Systems

Client Proof Libraries

Client Voice Architecture

Client Approval Rules

Offer Brain

Content Brain

Creative Brain

Sales Brain

Conversion Brain

Research Brain

Compliance Brain

future AIBS client systems

This standard applies to:

client documents

client source material

client offer profiles

client buyer profiles

client voice files

client objection libraries

client proof libraries

client workflows

client reports

client deliverables

client AI skills

client context packs

client asset drafts

client audit records

client approval notes

client tool permission notes

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

Core Definition

Client Context Isolation means that each client’s source material, context files, proof, voice, workflows, outputs, and AI skills remain separated from MWMS internal context and from other clients.

A Privacy Boundary defines what client material may be read, used, shared, generalized, archived, or promoted.

Client context must answer:

Who owns this material?

Which client does it belong to?

What may it be used for?

Who may review it?

Which AI Employees may use it?

Which outputs may reference it?

Can it be generalized?

Can it be used publicly?

Does it require approval?

Does it contain sensitive information?

Core Principle

The core principle of this standard is:

Client context belongs inside the client boundary unless deliberately approved for broader use.

Client material must not become general MWMS context by accident.

Client-specific insights must not be reused across clients unless they are stripped of identifying detail, generalized, reviewed, and approved.

Privacy and trust must be designed into AIBS from the beginning.

Client Context Boundary

Every future client system should have a clear boundary.

The boundary should define:

client name

client system name

client context library

client source folder

client output folder

client skill folder

client proof folder

client audit folder

client approval rules

client review owner

client privacy level

client tool permission rules

client archive rules

No client material should be stored in a general MWMS folder unless it has been deliberately generalized and approved.

Client Folder Structure

Recommended client structure:

Client Name/

01 Raw Client Material/

02 Client IP Excavation/

03 Client Context Library/

04 Client Skills And AI Employees/

05 Client Output Assets/

06 Client Reports/

07 Client Audits/

08 Client Archive/

09 Client Approval Records/

10 Client Restricted Material/

This structure keeps raw material, active context, outputs, audits, and restricted materials separated.

Client Context Library Files

A client context library may include:

Client Business Snapshot

Client Right-Fit Client Profile

Client Offer Profile

Client Voice Architecture

Client Differentiation Profile

Client Objection Library

Client Methodology Map

Client Expert Thinking Rules

Client Customer Language Bank

Client Proof Library

Client Brand Visual Style

Client Retired Language

Client Compliance Notes

Client Approval Rules

Client Reporting Preferences

Client Workflow Map

Client Tool Boundary Notes

Each file should clearly identify the client.

Client File Naming Rule

Client-specific files should include the client name or client identifier.

Examples:

Client A – Voice Architecture

Client A – Offer Profile

Client A – Objection Library

Client A – Proof Library

Client A – Report Draft – May 2026

Avoid vague names such as:

Voice Notes

Client Report

Offer Profile

Proof

Final

If the file could be confused with MWMS internal context or another client, the name is not clear enough.

Client Privacy Levels

MWMS uses the following privacy levels.

Internal MWMS Only

Material belongs to MWMS and is not client-owned.

Client-Specific Internal

Client material may be used internally for that client’s system only.

Client-Approved For Use

Client has approved use inside client-facing deliverables.

Client-Approved Public

Client has approved public-facing use.

Restricted

Material may be used only under specific conditions.

Confidential

Material should not be used in generated outputs unless explicitly approved.

Do Not Use

Material must not be used.

Archive Only

Material is preserved but not active.

Client Proof Boundary

Client proof is high-risk.

Client proof may include:

testimonials

case studies

screenshots

analytics

sales results

customer feedback

private examples

before-and-after results

client performance data

Client proof must not be used unless its approval status is clear.

Client proof must define:

source

claim supported

claim not supported

client approval status

public use permission

report use permission

ad use permission

privacy sensitivity

expiration or review date

Client proof must never be generalized into MWMS proof unless explicitly approved.

Client Voice Boundary

Client voice must stay client-specific.

A client Voice Architecture may include:

tone

phrases

CTA style

preferred wording

banned wording

founder phrases

brand language

retired language

examples

Client voice must not influence:

MWMS internal voice

another client’s voice

general AIBS templates

public MWMS content

unless generalized and approved.

AI Employees must not use one client’s tone or phrases for another client.

Client Skill Boundary

Client-specific skills must stay inside that client system.

Examples:

Client A Content Brief Skill

Client A Sales Follow-Up Skill

Client A Voice Checker Skill

Client A Monthly Report Draft Skill

Client A Objection Response Skill

Client-specific skills may depend on:

client voice

client offer

client proof

client workflow

client approval rules

client reporting format

These dependencies make them unsafe to reuse elsewhere without review.

A client skill can become a general MWMS skill only when:

client-specific information is removed

procedure is generalized

client approval is not required or has been granted

HeadOffice reviews it

AI Business Systems Brain approves it

the skill is renamed and re-scoped

Client Output Boundary

Client output assets may include:

reports

emails

content drafts

sales assets

lead magnets

webinars

landing pages

workflow documents

strategy notes

AI system explanations

Client outputs are not automatically MWMS assets.

They remain client-specific unless generalized and approved.

Client outputs must not be reused as examples, templates, case studies, or proof without approval.

Client Context Pack Boundary

Client context packs must include only the relevant client’s context.

A client context pack should not load:

another client’s files

MWMS internal proof

unrelated offer context

unapproved public examples

stale drafts

archive files

A client context pack should include:

client name

task

approved client context files

client approval rules

client proof limits

client privacy level

forbidden actions

review requirement

handoff destination

Client Approval Rules

Client approval is required before using:

client testimonials publicly

client screenshots publicly

client performance data publicly

client reports externally

client case studies

client private workflows

client customer language publicly

client brand voice examples in MWMS marketing

client deliverables as portfolio material

client AI skills as generalized templates

Client approval should be recorded.

Approval records should include:

what was approved

who approved it

date

scope of approval

usage permission

expiration or review date where relevant

Client Generalization Rule

Client material may be generalized only when:

specific client identifiers are removed

private details are removed

sensitive data is removed

proof is not transferred without permission

process is abstracted

approval is obtained where required

HeadOffice reviews generalization

AI Business Systems Brain approves broader use

Example:

Client-specific workflow:

Client A uses a seven-step onboarding process for their coaching offer.

Potential generalized learning:

Future client systems may need a Client Onboarding Workflow Map file.

Do not copy the client’s exact process unless approved.

Client Data Minimization Rule

MWMS should collect only the client material needed for the task.

Do not request or store unnecessary sensitive data.

Avoid collecting:

passwords

private financial details

personal identification

unnecessary customer data

private health information

confidential legal material

employee personal information

unless explicitly required, permissioned, and handled under separate governance.

Client Tool Boundary

Client tool access is separate from client context access.

This standard does not grant tool permission.

Client tool use must define:

which tool

which account

what access level

read or write

human approval required

what actions are forbidden

what data may be accessed

what data must not be accessed

AI Employees must not assume tool access from client context.

Client Boundary Decision Template

Use this template when classifying client material.

Client Name:

Material Name:

Material Type:

Source:

Privacy Level:

Approved Use:

Restricted Use:

Do Not Use For:

Client Approval Required:

Public Use Allowed:

Internal Use Allowed:

Client-Facing Use Allowed:

Can Be Generalized:

Generalization Conditions:

Review Owner:

Next Review Date:

Notes:

Minimum Client Boundary Template

For quick decisions:

Client:

Material:

Privacy Level:

Allowed Use:

Approval Required:

Can Generalize:

Next Action:

Client Isolation Rules

Rule 1: One Client Context Per Client Task

Do not mix client contexts unless the task explicitly requires comparison and permission exists.

Rule 2: Client Context Is Not MWMS Context

Client material must not enter general MWMS context by default.

Rule 3: Client Proof Requires Approval

Do not use client proof without approval status.

Rule 4: Client Voice Must Stay Isolated

Do not reuse client voice across clients.

Rule 5: Client Skills Must Stay Client-Specific

Do not generalize client skills without review.

Rule 6: Client Outputs Are Not Templates By Default

Client assets may inspire general frameworks only after review.

Rule 7: Client Approval Records Must Be Preserved

Approval scope must be traceable.

Rule 8: Sensitive Data Should Be Minimized

Collect only what is needed.

Rule 9: Tool Access Is Separate

Context permission does not equal tool permission.

Rule 10: Archive Does Not Mean Active

Old client files must not be used unless reactivated or reviewed.

Client Isolation Failure Modes

MWMS must prevent:

wrong client context used

client proof reused elsewhere

client voice leaking into another client

client reports built from wrong context

client data copied into general MWMS pages

client workflows turned into templates without approval

client assets used publicly without permission

client screenshots exposed

client private notes used in public marketing

client tool access assumed

client archive material used as active truth

AI Employees blending multiple client libraries

Client Context Audit

Client context libraries should be audited regularly.

Audit questions:

Are client files isolated?

Are active and archived files separated?

Are approval records clear?

Is proof approved?

Is voice current?

Are client workflows current?

Are client skills still correct?

Are client reports using correct context?

Are any client materials in general MWMS folders?

Are any client assets being reused without approval?

Are privacy levels current?

Audit outcomes:

Current

Needs Cleanup

Needs Client Review

Needs Approval Update

Needs Archive

Needs Restriction

Needs Deletion Review

Client Exit Or Pause Rule

If a client relationship ends or pauses, MWMS must classify client materials.

Possible outcomes:

keep active under agreement

archive

restrict

delete if required and approved

retain approved generalized learning

remove tool access

pause skills

pause reporting

record closeout

Client exit or pause must not leave client material floating.

Governance Role

AI Business Systems Brain owns the MWMS Client Context Isolation And Privacy Boundary Standard.

HeadOffice governs cross-system source truth, privacy boundaries, and escalation.

Compliance Brain governs sensitive, regulated, public, claims, and privacy-risk usage.

Client-specific Brain owners are responsible for maintaining their own client boundaries.

AI Business Systems Brain is responsible for:

client folder structure

client context isolation

client approval rules

client-specific skill boundaries

client proof boundaries

client report boundaries

client generalization approval

future AIBS delivery trust

HeadOffice is responsible for:

ensuring client context does not leak into general MWMS systems

ensuring registry and source-of-truth alignment

ensuring high-risk client material is escalated

ensuring client boundaries remain visible to AI Employees

Relationship To Other MWMS Standards

This standard supports and must align with:

MWMS Document Structure Standard

MWMS Client Brain Intake And Onboarding Protocol

MWMS Client IP Excavation Framework

MWMS Source Material Intake And Evidence Inventory Checklist

MWMS Context File Promotion And Approval Protocol

MWMS Context Library Governance And Folder Map Standard

MWMS Context Library Hygiene And Retired Language Rule

MWMS Missing Context And Evidence Gap Handling Rule

MWMS Minimum Viable Context Library Rule

MWMS Offer Context Library Standard

MWMS AI Context Activation And Usage Protocol

MWMS AI Context Pack Template Standard

MWMS Voice Architecture And Brand Language Standard

MWMS Proof Library And Claims Control Standard

MWMS AI Brain Readiness Review Checklist

MWMS AI Brain Audit And Decay Prevention Framework

MWMS AI Skill Installation And Usage Protocol

MWMS AI Brain Page And Asset Registry Standard

AI Business Systems Brain Canon

This standard provides the client isolation and privacy boundary layer required for safe future AIBS delivery.

Drift Protection

This standard protects MWMS from:

client context leakage

wrong client context use

client proof misuse

client voice contamination

client workflow overgeneralization

client skill reuse without approval

client asset reuse without permission

client report errors

client privacy risk

AIBS trust erosion

Any client-specific material used outside its approved client boundary should be treated as a client context drift risk.

Architectural Intent

The architectural intent of the MWMS Client Context Isolation And Privacy Boundary Standard is to make future AIBS delivery trustworthy, governable, and scalable.

MWMS will eventually support multiple client Brains and AI Business Systems.

That cannot work unless each client’s context remains separated, permissioned, and reviewable.

The long-term goal is that every client-specific material can answer:

Which client owns this?

Where does it live?

What privacy level applies?

What can it be used for?

What must it not be used for?

Is client approval required?

Can it be public?

Can it be generalized?

Can an AI Employee use it?

Which outputs depend on it?

When MWMS can answer these questions consistently, client AI systems can scale without leaking context, weakening trust, or creating operational risk.

Change Log

v1.0 — Initial Draft

Created the MWMS Client Context Isolation And Privacy Boundary Standard as the standard for separating, protecting, scoping, reviewing, and governing client-specific context, proof, voice, workflows, skills, reports, outputs, approval records, and future AIBS client systems.

This standard defines client context boundaries, client folder structure, client files, naming rules, privacy levels, proof boundaries, voice boundaries, skill boundaries, output boundaries, context pack boundaries, approval rules, generalization rules, data minimization, tool boundaries, templates, isolation rules, failure modes, audit rules, client exit or pause rules, governance role, drift protection, and architectural intent.

Change Impact Declaration

Pages Created:

MWMS Client Context Isolation And Privacy Boundary Standard

Pages Updated:

None

Pages Deprecated:

None

Registries Requiring Update:

MWMS Architecture Registry

AI Business Systems Brain Page Registry

HeadOffice Page Registry

Compliance Brain Page Registry

Client Asset Registry

Canon Version Update Required:

No

Change Log Entry Required:

Yes

Employee Impact Check

Employees impacted:

AI Business Systems Architect Employee

HeadOffice Manager Employee

AI Manager

AI Employee Router

Client IP Excavator

Context Library Builder

Skill Auditor

Content Planner Employee

Offer Strategist Employee

Creative Strategist Employee

Sales Strategist Employee

Research Analyst Employee

Compliance Reviewer Employee

Required behaviour updates:

AI Employees must keep client-specific context, proof, voice, workflows, reports, skills, outputs, and approval records isolated from MWMS internal context and other client systems.

AI Employees must not reuse client proof, client voice, client workflows, client outputs, or client-specific skills outside the client boundary without approval and generalization review.

AI Employees must identify client privacy level, allowed use, restricted use, approval requirement, and generalization conditions before using client material.

AI Employees must not assume client tool access from client context permission.

AI Employees must flag any client material appearing in general MWMS folders, cross-client outputs, or public-facing assets without approval.

END MWMS CLIENT CONTEXT ISOLATION AND PRIVACY BOUNDARY STANDARD v1.0