System: MWMS
Document Type: Protocol
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AI Business Systems Brain, AI Manager, AI Employee Router, Brain Room, Course Absorption System, Content Brain, Offer Brain, Sales Brain, Creative Brain, Conversion Brain, Research Brain, Compliance Brain, Future AIBS Client Systems
Parent Page: HeadOffice
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 Context Change Propagation And Dependency Map Protocol.
This protocol establishes how MWMS identifies, traces, and updates related context files, skills, assets, Brains, AI Employees, registries, and review pathways when one important context element changes.
MWMS must not treat context files as isolated documents.
When one context file changes, other files may also need updating.
Examples:
If the offer promise changes, the Offer Profile is not the only file affected.
The Right-Fit Client Profile, Differentiation Profile, Objection Library, Proof Library, Retired Language, Sales Brain assets, Content Brain briefs, Ads Brain angles, lead magnet assets, webinar assets, and AI Employee instructions may also be affected.
If voice changes, old phrases may need to be retired.
If proof changes, claims may need to be softened or removed.
If the buyer changes, content, ads, sales scripts, webinars, and lead magnets may need review.
This protocol exists to prevent isolated updates from creating system-wide drift.
Without context change propagation, MWMS risks:
old offer promises remaining active
old buyer profiles guiding new content
retired language appearing in ads
proof being used after it becomes restricted
skills using stale context
AI Employees following outdated rules
client systems producing outdated assets
sales pages and emails becoming misaligned
MCR pages staying correct while operational assets drift
future AIBS systems becoming unreliable
The Context Change Propagation And Dependency Map Protocol ensures that important changes move through the ecosystem deliberately.
Scope
This protocol applies to all MWMS context libraries, Brain files, offer files, client files, skill files, asset systems, proof libraries, voice files, and future AIBS client systems.
This includes:
HeadOffice Brain
AI Business Systems Brain
AI Manager
AI Employee Router
Brain Room
Course Absorption System
Newsletter Intelligence
Opportunity System
Offer Brain
Content Brain
Creative Brain
Sales Brain
Conversion Brain
Customer Brain
Research Brain
Affiliate Brain
Ads Brain
Compliance Brain
future AIBS client systems
This protocol applies when changes occur to:
Right-Fit Client Profile
Offer Profile
Voice Architecture
Differentiation Profile
Objection Library
Methodology Map
Expert Thinking Rules
Customer Language Bank
Proof Library
Retired Language
Compliance Notes
Brand Visual Style
Client Approval Rules
Client Workflow Map
AI Skill Records
AI Employee Role Cards
MCR standards
asset frameworks
public-facing assets
client-facing assets
This protocol does not authorize development work, plugin changes, Supabase changes, WordPress changes, automation wiring, publishing, file deletion, client implementation, or M developer action.
Core Definition
Context Change Propagation is the process of identifying which related files, assets, skills, Brains, AI Employees, or workflows must be reviewed or updated after a context change.
A Dependency Map is the record of what other system parts depend on a specific context file or rule.
Context changes may affect:
source truth
AI output
asset accuracy
claims safety
voice consistency
offer positioning
buyer relevance
skill behaviour
Brain routing
client system reliability
A context change is not complete until its dependencies have been checked.
Core Principle
The core principle of this protocol is:
When source truth changes, all dependent outputs and systems must be reviewed for drift.
MWMS must not update one file and assume the rest of the system will automatically remain aligned.
Context change must travel.
Change Types
MWMS recognizes several context change types.
Offer Change
The offer changes.
Examples:
new promise
new price
new delivery model
new inclusions
new exclusions
new bonus
new next step
new risk reversal
Buyer Change
The buyer changes.
Examples:
new target segment
old segment no longer fits
buyer sophistication changes
buyer urgency changes
buyer objections change
Voice Change
The brand or founder voice changes.
Examples:
new tone
new preferred phrases
banned phrases
retired language
new CTA style
less hype
more directness
Proof Change
Proof changes.
Examples:
new testimonial
proof removed
proof restricted
case study expired
performance data updated
vendor claim changed
Methodology Change
The process changes.
Examples:
new first step
new sequence
old step removed
new framework name
delivery method updated
Expert Thinking Change
Decision logic changes.
Examples:
new if/then rule
new diagnostic check
new escalation rule
new rejection criteria
Compliance Change
Rules or risk constraints change.
Examples:
Google Ads issue
affiliate claim restriction
privacy rule
health claim sensitivity
financial claim sensitivity
testimonial restriction
Client Change
Client-specific context changes.
Examples:
client offer update
client approval rule update
client voice update
client workflow update
client privacy rule update
Skill Change
A skill procedure changes.
Examples:
new trigger
new required context
new output format
new validation rule
new forbidden action
Asset Change
An asset changes.
Examples:
lead magnet updated
webinar updated
landing page updated
sales page updated
VEO3 script updated
Dependency Principle
Each major context file has dependencies.
A dependency means another file, asset, skill, Brain, or AI Employee uses that context.
If the source context changes, dependent materials may need review.
Not every dependency needs immediate rewriting.
But every important dependency must be checked.
Primary Dependency Map
Right-Fit Client Profile Dependencies
When the Right-Fit Client Profile changes, review:
Offer Profile
Differentiation Profile
Objection Library
Customer Language Bank
Content plans
Lead magnets
Webinars
Sales pages
Landing pages
Ad angles
VEO3 scripts
Sales scripts
Client reports
AI Context Packs
AI skills that use buyer context
Offer Profile Dependencies
When the Offer Profile changes, review:
Right-Fit Client Profile
Differentiation Profile
Objection Library
Proof Library
Retired Language
Compliance Notes
Sales pages
Landing pages
Lead magnets
Webinars
Email sequences
Ad scripts
VEO3 scripts
Affiliate bridge pages
Client reports
AI Employee instructions
Offer-related skills
Voice Architecture Dependencies
When Voice Architecture changes, review:
Retired Language
Content templates
Email templates
VEO3 scripts
Ad scripts
Sales scripts
Landing page copy
Client report style
CTA style
Social content
Voice Checker Skill
Content Brain outputs
Creative Brain outputs
Sales Brain outputs
Differentiation Profile Dependencies
When Differentiation Profile changes, review:
Offer Profile
Objection Library
Content angles
Ad hooks
Webinar problem reframe
Lead magnet angle
Sales page positioning
Landing page headline
Email sequence
Creative briefs
Affiliate bridge copy
Objection Library Dependencies
When Objection Library changes, review:
Sales scripts
FAQ sections
Webinars
Lead magnets
Landing pages
Sales pages
Email sequences
Retargeting content
Client reports
Offer evaluation assets
Sales Brain skills
Conversion Brain assets
Proof Library Dependencies
When Proof Library changes, review:
Claims Control
Sales pages
Landing pages
Ads
Emails
Webinars
Case studies
Client reports
Affiliate bridge pages
VEO3 scripts
Compliance Notes
Proof Review Skill
Paid traffic assets
Compliance-sensitive outputs
Retired Language Dependencies
When Retired Language changes, review:
Content assets
Emails
Sales pages
Landing pages
Ads
VEO3 scripts
Lead magnets
Webinars
Client-facing outputs
Affiliate bridge pages
AI skills that generate copy
Voice Checker Skill
Compliance review paths
Compliance Notes Dependencies
When Compliance Notes change, review:
Proof Library
Claims Control
Ads
Affiliate assets
Sales pages
Landing pages
Emails
Webinars
Public-facing content
Client reports
Paid traffic assets
Compliance-sensitive skills
Methodology Map Dependencies
When Methodology Map changes, review:
Offer Profile
Expert Thinking Rules
Webinars
Lead magnets
Sales pages
Client reports
AI Employee workflows
Skill procedures
Context-driven assets
Training material
Expert Thinking Rules Dependencies
When Expert Thinking Rules change, review:
AI Employee role cards
AI skills
Review workflows
Decision trees
Audit checklists
Client reports
Offer evaluations
Research workflows
Sales diagnosis assets
Customer Language Bank Dependencies
When Customer Language Bank changes, review:
Content briefs
Ad hooks
Headlines
Landing pages
Emails
Sales pages
Webinars
Lead magnets
Objection Library
VOC-related skills
Brand Visual Style Dependencies
When Brand Visual Style changes, review:
Thumbnail briefs
Banner briefs
VEO3 prompts
Image prompts
Landing page visual direction
Creative briefs
Client brand assets
AI Studio workflows
Client Approval Rules Dependencies
When Client Approval Rules change, review:
Client reports
Client assets
Client skills
Client context packs
Client proof usage
Client-facing workflows
AIBS delivery process
Change Severity Levels
MWMS uses five change severity levels.
Level 1: Minor Edit
Small wording correction.
Usually no dependency review needed.
Example:
spelling correction.
Level 2: Clarification
Meaning is clarified but not changed.
Light dependency check may be enough.
Example:
better wording of an existing offer inclusion.
Level 3: Meaning Change
Meaning changes.
Dependency review required.
Example:
offer promise changes.
Level 4: Operational Change
Change affects workflows, skills, assets, or AI Employee behaviour.
Dependency review required and may require updates.
Example:
new required human review gate.
Level 5: Risk Change
Change affects compliance, claims, client privacy, paid traffic, finance, or developer risk.
Immediate review required.
Example:
proof item restricted or ad phrase retired after disapproval.
Propagation Workflow
MWMS uses the following workflow.
Step 1: Identify The Change
Define what changed.
Step 2: Classify Change Type
Offer, buyer, voice, proof, methodology, expert thinking, compliance, client, skill, or asset.
Step 3: Classify Severity
Level 1 through Level 5.
Step 4: Identify Owning Brain
Assign responsibility.
Step 5: Identify Dependencies
Use the Dependency Map.
Step 6: Decide Review Scope
Determine which files, skills, assets, or Brains need checking.
Step 7: Update Source File
Apply the source change.
Step 8: Review Dependent Items
Check whether dependent items now drift.
Step 9: Update, Park, Retire, Or Restrict
Take action on affected items.
Step 10: Record Change
Update change log, registry, audit record, or closeout where required.
Step 11: Notify Relevant AI Employees
Update behaviour requirements where needed.
Propagation Decision Template
Use this template.
Change Name:
Change Type:
Source File Changed:
Owning Brain:
Severity Level:
What Changed:
Why It Changed:
Affected Files:
Affected Assets:
Affected Skills:
Affected Brains:
Affected AI Employees:
Risk Areas:
Review Required:
Updates Required:
Items To Park:
Items To Retire:
Registry Impact:
Change Log Required:
Next Action:
Notes:
Minimum Propagation Template
For quick use:
Changed:
Type:
Severity:
Dependencies:
Action:
Review Required:
Next Step:
Update Actions
After dependency review, each affected item should receive one action.
No Change Needed
Item remains aligned.
Update Required
Item must be revised.
Restrict
Item may still be used but only under conditions.
Retire
Item should no longer be used.
Archive
Item should be preserved but inactive.
Park
Item may be useful later but not now.
Human Review Required
Item cannot be decided by AI alone.
Compliance Review Required
Claim or risk review is required.
Client Review Required
Client-owned material must be reviewed.
Change Log Rules
A change log entry may be required when:
document structural logic changes
governance relationships change
behavioural meaning changes
source truth changes
active context meaning changes
client context changes
proof or claim rules change
AI Employee behaviour changes
routine formatting changes do not automatically require monthly change log entry.
When required, state:
Please add this to Change Log Month
Registry Impact Rules
Registry update may be required when:
new page created
page status changes
page deprecated
page retired
page parked
page owner changes
Brain responsibility changes
client asset status changes
skill status changes
context file status changes
AI Employee impact changes
The registry should reflect actual current status.
Employee Impact Rules
AI Employee behaviour may need updating when:
required context changes
forbidden actions change
output format changes
validation rules change
handoff destination changes
review requirement changes
tool permission boundary changes
risk classification changes
Retired Language changes
proof restrictions change
When AI Employee behaviour changes, include an Employee Impact Check.
Client Change Propagation Rules
Client context changes require strict isolation.
If a client file changes, review only that client’s dependencies unless the insight is deliberately generalized and approved.
Client changes may affect:
client context library
client skills
client reports
client lead magnets
client webinars
client voice checker
client approval rules
client proof library
client workflow map
Client changes must not automatically update general MWMS context.
Affiliate Change Propagation Rules
Affiliate offers require careful propagation because vendor pages, claims, payouts, compliance rules, and platform policies may change.
If affiliate offer context changes, review:
affiliate offer profile
proof library
claims control
landing pages
ads
VEO3 scripts
emails
bridge pages
retired language
compliance notes
BeMob or tracking notes where relevant
Affiliate Brain, Ads Brain, and Compliance Brain may need review.
Paid Traffic Change Propagation Rules
Paid traffic assets require immediate review when changes involve:
ad disapproval
claim restriction
landing page mismatch
proof restriction
offer promise change
CTA change
policy change
retired phrase
target buyer change
Affected items may include:
ads
landing pages
VEO3 scripts
YouTube descriptions
thumbnails
headlines
email pre-frame
bridge pages
tracking notes
Common Failure Modes
MWMS must prevent:
updating one file while dependent files stay stale
changing offer promise without reviewing sales assets
changing buyer profile without reviewing content
adding proof without claims control
restricting proof without updating sales pages
retiring language without checking ads
changing voice without updating templates
changing methodology without updating skills
client changes leaking into general MWMS
affiliate claim changes not reaching ads
paid traffic risks staying active
AI Employees using old context after source truth changes
Governance Role
HeadOffice owns the MWMS Context Change Propagation And Dependency Map Protocol.
HeadOffice is responsible for:
ensuring important context changes are classified
ensuring dependencies are reviewed
ensuring source truth updates do not create downstream drift
ensuring registries are updated when required
ensuring AI Employee impact is captured
ensuring high-risk changes are reviewed
ensuring client context remains isolated
ensuring affiliate and paid traffic changes reach relevant Brains
Individual Brains are responsible for reviewing dependencies within their domain.
Offer Brain governs offer, buyer, differentiation, objection, methodology, and proof dependencies.
Content Brain governs content and voice dependencies.
Sales Brain governs sales asset dependencies.
Creative Brain governs creative asset dependencies.
Conversion Brain governs funnel and landing page dependencies.
Compliance Brain governs claims and risk dependencies.
AI Business Systems Brain governs client system dependencies.
Relationship To Other MWMS Standards
This protocol supports and must align with:
MWMS Document Structure Standard
MWMS Context File Promotion And Approval Protocol
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 Context Library Governance And Folder Map Standard
MWMS AI Context Activation And Usage Protocol
MWMS AI Context Pack Template Standard
MWMS Voice Architecture And Brand Language Standard
MWMS Right-Fit Client And Offer Profile Standard
MWMS Differentiation And Objection Library Standard
MWMS Proof Library And Claims Control Standard
MWMS AI Brain Audit And Decay Prevention Framework
MWMS AI Brain Page And Asset Registry Standard
MWMS AI Brain Build Handoff And Closeout Standard
MWMS AI Output Validation Standard
MWMS Brain Routing Rule
MWMS MCR Promotion To Brain Protocol
MWMS Architecture Registry
AI Business Systems Brain Canon
This protocol provides the dependency and propagation layer for context changes across MWMS.
Drift Protection
This protocol protects MWMS from:
isolated context updates
stale dependent files
old offer promises
wrong buyer targeting
proof restriction failures
retired language returning
skills using old context
assets using old claims
client context leakage
affiliate claim drift
paid traffic compliance drift
AI Employees following outdated source truth
Any meaningful context change made without dependency review should be treated as a propagation drift risk.
Architectural Intent
The architectural intent of the MWMS Context Change Propagation And Dependency Map Protocol is to keep MWMS aligned when source truth changes.
MWMS is a connected ecosystem.
A change in one context file can affect many outputs, skills, Brains, and AI Employees.
The long-term goal is that every important context change can answer:
What changed?
Why did it change?
How severe is it?
Which files depend on it?
Which assets depend on it?
Which skills depend on it?
Which Brains are affected?
Which AI Employees must change behaviour?
What needs review?
What needs updating?
What needs retiring?
What needs registry update?
When MWMS can answer these questions consistently, the system can evolve without drifting apart.
Change Log
v1.0 — Initial Draft
Created the MWMS Context Change Propagation And Dependency Map Protocol as the protocol for identifying and updating related files, skills, assets, Brains, AI Employees, registries, and review pathways when important context changes occur.
This protocol defines change types, dependency principles, dependency map, severity levels, propagation workflow, templates, update actions, change log rules, registry impact rules, employee impact rules, client propagation rules, affiliate propagation rules, paid traffic propagation rules, failure modes, governance role, drift protection, and architectural intent.
Change Impact Declaration
Pages Created:
MWMS Context Change Propagation And Dependency Map Protocol
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
HeadOffice Page Registry
AI Business Systems Brain Page Registry
Offer Brain Page Registry
Content Brain Page Registry
Sales Brain Page Registry
Creative Brain Page Registry
Conversion Brain Page Registry
Compliance Brain Page Registry
Affiliate Brain Page Registry
Ads Brain Page Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes
Employee Impact Check
Employees impacted:
HeadOffice Manager Employee
AI Manager
AI Employee Router
Context Library Builder
Client IP Excavator
Skill Auditor
Offer Strategist Employee
Content Planner Employee
Creative Strategist Employee
Sales Strategist Employee
Conversion Strategist Employee
Research Analyst Employee
Compliance Reviewer Employee
Affiliate Offer Evaluator Employee
Ads Strategist Employee
AI Business Systems Architect Employee
Required behaviour updates:
AI Employees must identify dependent files, assets, skills, Brains, and AI Employees when important context changes occur.
AI Employees must not treat context files as isolated when offer, buyer, voice, proof, methodology, compliance, client, affiliate, or paid traffic context changes.
AI Employees must classify change severity and route high-risk changes to the appropriate review path.
AI Employees must recommend updates, restrictions, parking, retirement, archive, registry updates, and employee behaviour changes where dependencies are affected.
AI Employees must preserve client isolation and prevent client-specific changes from automatically altering general MWMS context.
END MWMS CONTEXT CHANGE PROPAGATION AND DEPENDENCY MAP PROTOCOL v1.0