System: MWMS
Document Type: Governance Protocol
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.0
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, Dev Console, AI Manager, M Developer Workflow, Course Absorption System, Research Brain, Experimentation Brain, Affiliate Brain, PPL Brain, AIBS Brain, Content Brain, Ads Brain, Finance Brain, Risk Brain, Compliance Brain, SIT Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-02
Source / Origin: Martyn Strategic Correction Session — Plus Drift / Human Challenge / MWMS Vision Protection Discussion
MWMS Classification: AI Governance Protocol / Drift Control Standard / Human Authority Rule / Developer Challenge Protocol / Vision Protection Layer
Primary Brain: HeadOffice Brain
Supporting Brains: MWMS Brain, Research Brain, Experimentation Brain, Affiliate Brain, PPL Brain, AIBS Brain, Content Brain, Ads Brain, Finance Brain, Risk Brain, Compliance Brain, SIT Brain, Automation Brain, Operations Brain, Data Brain
Related Pages: MWMS Offer And Niche Selection Framework, MWMS AI Agent Operations Core, MWMS AI Agent Memory And Context Framework, MWMS Context Engineering Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Automation Security And Risk Checklist, MWMS AI Output Standard Full File Delivery Rule, MWMS Course Absorption Operating Rule, MWMS Course Absorption Handoff Standard, MWMS Missing Context And Evidence Gap Handling Rule, MWMS Source Visibility And Evidence Display Standard, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol, MWMS Architecture Registry, HeadOffice Kaizen Continuous Improvement Loop, Experimentation Brain Canon, Research Brain Canon, AIBS Brain Canon, Affiliate Brain Canon, PPL Brain Canon, SIT Brain Canon

Purpose

The purpose of the MWMS Plus Drift Control And Human Challenge Protocol is to protect MWMS from blindly following ChatGPT / Plus / AI assistant outputs when those outputs drift from Martyn’s vision, skip required reasoning stages, ignore established rules, assume facts without evidence, create unnecessary pages, or give M unclear build direction.

This protocol exists because MWMS depends heavily on AI-assisted thinking, course absorption, page creation, system design, developer instructions, and strategic planning.

That creates a real risk.

The risk is not that AI is useless.

The risk is that AI can sound confident while being wrong, incomplete, misrouted, over-productive, biased by recent context, or misaligned with the deeper MWMS vision.

Inside MWMS, Plus may:

drift inside a single conversation
forget rules after being reminded
over-focus on the most recent Brain
assume page ownership too quickly
create page bloat
suggest unnecessary frameworks
skip Research Brain
skip Experimentation Brain
treat assumptions as structure
give vague developer instructions
assume a page exists without checking
update a page without the current source page
create output in the wrong format
move too fast from course material to MCR pages
overweight AIBS while underweighting Affiliate or PPL
produce confident but unverified strategy
lead M into work that does not serve Martyn’s vision

This protocol makes the correct authority clear:

Plus proposes.
Martyn decides.
M challenges.
HeadOffice governs.
Research validates.
Experimentation proves.
Execution Brains act only after upstream intelligence is clear.

This protocol exists to stop MWMS from being quietly shaped by AI drift instead of Martyn’s vision.

Core Problem

The core problem is that Plus can drift quickly.

Even when Martyn reminds Plus of the rules, Plus may still:

use the wrong output format
create a partial page instead of full page output
suggest a page without reading the current page
assume Brain ownership too early
create a page when an update would be better
update a page before confirming the base version
over-produce instead of protecting focus
treat a course lesson as more important than it is
follow recent conversation bias instead of MWMS architecture
skip the proper upstream flow of Research → Experimentation → Execution

This creates pain because Martyn’s vision is the north star, but M may follow Plus because Plus appears confident.

That means Plus drift can become build drift.

Build drift can become wasted time.

Wasted time can become system bloat.

System bloat can weaken MWMS.

This protocol exists to stop that.

Core Doctrine

The MWMS doctrine is:

AI output is not authority.
AI output is a proposal.
Human authority decides whether it becomes MWMS direction.

Plus must not be treated as the final decision-maker.

Plus must be treated as a powerful but fallible strategy assistant.

The system must assume that Plus can drift.

Therefore, every serious Plus output must be challengeable.

Authority Hierarchy

MWMS follows this authority hierarchy.

Highest Authority

Martyn’s explicit current instruction
MWMS vision as defined by Martyn
MCR source-of-truth pages
HeadOffice governance
Current file, screenshot, database, page, or system evidence
Current approved save point
Brain Canon rules
Research Brain validated evidence
Experimentation Brain test evidence
Plus/Chat output
Memory
General AI knowledge

Rule

Plus output sits below Martyn, MCR, HeadOffice, current evidence, Brain Canon, Research validation, and Experimentation validation.

Plus output must never override those authority layers.

Definition

Plus Drift is when ChatGPT / Plus / AI assistant output moves away from Martyn’s actual vision, current instruction, MCR source of truth, evidence, correct Brain routing, required workflow sequence, or operational usefulness.

MWMS Definition

Plus Drift is:

Any AI-generated direction, page, update, strategy, build instruction, or recommendation that sounds useful but is not properly aligned with Martyn’s vision, current evidence, MCR authority, Brain ownership, Research validation, Experimentation validation, or MWMS execution discipline.

Scope

This protocol applies to:

course absorption
newsletter absorption
MCR page creation
MCR page updates
Brain page updates
developer instructions for M
Brain Room recommendations
Dev Console guidance
AI Manager outputs
AI Employee routing
task creation
build planning
offer selection
niche selection
avatar creation
affiliate offer evaluation
PPL vertical selection
AIBS package design
Content Brain strategy
Ads Brain campaign planning
Research Brain outputs
Experimentation Brain test design
Finance Brain forecasting
Compliance Brain review
Risk Brain review
SIT Brain testing
any output that may affect MWMS direction, build, cost, workload, or architecture

This protocol applies whenever Plus suggests that MWMS should:

create a page
update a page
build something
change direction
route work to a Brain
ask M to do something
treat a course insight as important
treat an assumption as fact
accept a strategic recommendation
move from idea to execution

Core Rule 1: Plus Proposes, Martyn Decides

Plus may suggest.

Plus may recommend.

Plus may analyse.

Plus may draft.

Plus may challenge.

Plus may warn.

Plus may create options.

But Plus does not decide MWMS direction.

Martyn decides.

Rule

No Plus recommendation becomes MWMS direction until Martyn accepts it.

Core Rule 2: M Has Full Challenge Authority

M must not treat Plus as the boss.

M is allowed and expected to challenge Plus when the output is unclear, risky, vague, unverified, misaligned, or technically unsafe.

M may challenge:

vague build instructions
unsupported assumptions
missing file paths
unclear insertion points
wrong site/domain references
outdated save points
memory-based claims
instructions that touch active build areas
instructions that ignore screenshots
instructions that skip current evidence
instructions that conflict with Martyn’s latest direction
instructions that seem like page theory instead of build requirement
instructions that create unnecessary complexity
instructions that move too fast into development

M Challenge Standard

M should be able to say:

“I am not implementing this until the instruction is clear, evidence-based, file-specific, and approved by Martyn.”

That is not resistance.

That is system protection.

Core Rule 3: Current Evidence Beats Memory

Plus must not rely on memory when current evidence is required.

This applies especially to:

WordPress page existence
current MCR page content
plugin files
Supabase tables
screenshots
Google Ads screens
Make scenarios
n8n workflows
current domain/site state
M’s active build state
current task status

Rule

If current evidence is needed and Plus has not checked it, Plus must not claim certainty.

Core Rule 4: No Page Update Without Current Page

A page must not be updated unless the actual current page is supplied, uploaded, pasted, or otherwise inspected.

Plus must not update from memory unless Martyn explicitly asks for a draft concept only.

Rule

No current page, no formal full-page update.

Core Rule 5: No New Page Without Drift Check

Before creating a new MCR page, Plus must perform a Drift Check.

Drift Check Questions

Ask:

Is this actually new value?
Is this already covered by an existing page?
Does it belong as an update instead?
Does it belong upstream in Research Brain?
Does it require Experimentation Brain validation?
Does it affect Affiliate, PPL, AIBS, or multiple Brains?
Is Plus over-focusing on the most recent Brain?
Is this page operationally useful?
Would Martyn use this to decide?
Would M use this to build?
Does it reduce confusion or add clutter?
Does this serve Martyn’s vision?
Is this course material strong enough to justify a page?
Is this a system standard, or just a useful note?
Is this a parked idea with trigger, not an active page?

Rule

If the page does not survive Drift Check, do not create it.

Core Rule 6: Course Absorption Must Not Become Page Bloat

Course absorption exists to strengthen MWMS, not to create pages for every lesson.

A course block may produce:

no action
one small note
one page update
one new page
multiple pages only if the block is genuinely system-changing

Rule

Most course material should not become new MCR pages.

Only high-value, reusable, operationally important material should become MCR structure.

Core Rule 7: Research Brain Comes Before Avatar, Offer, Funnel, And Campaign

MWMS must not build around assumed avatars.

Research Brain must define the avatar hypothesis before execution Brains act.

This applies to:

affiliate campaigns
PPL verticals
AIBS packages
content strategies
paid ad campaigns
lead magnets
DTC products
AIOS packages
outbound campaigns
landing pages
VEO3 hooks
YouTube campaigns

Rule

No serious offer, funnel, campaign, or client package should be built on an unresearched avatar.

Core Rule 8: Experimentation Brain Must Validate Hypotheses

Research Brain creates hypotheses.

Experimentation Brain tests them.

A hypothesis may include:

avatar
pain point
channel
offer
pricing
funnel
hook
lead magnet
traffic source
PPL vertical
affiliate angle
AIBS package
client willingness to pay

Rule

A hypothesis is not truth until tested.

Core Rule 9: Execution Brains Must Not Skip Upstream Intelligence

Affiliate Brain, PPL Brain, AIBS Brain, Content Brain, and Ads Brain should not rush into execution without upstream intelligence.

The default flow should be:

Research Brain defines market and avatar hypothesis
Experimentation Brain defines test
Finance Brain checks economics where needed
Compliance/Risk Brain checks exposure where needed
Execution Brain performs controlled action
Results return to Experimentation and Research
HeadOffice decides next step

Rule

Execution without upstream intelligence increases drift risk.

Core Rule 10: AIBS Must Not Crowd Out Affiliate And PPL

AIBS is important, but it must not become the only lens.

MWMS has multiple commercial engines.

These include:

Affiliate Brain
PPL Brain
AIBS Brain

Plus must not over-route broad commercial insights into AIBS just because recent course material has focused on AI automation.

Rule

When a lesson affects multiple commercial engines, route it cross-Brain instead of AIBS-only.

Core Rule 11: Developer Instructions Must Be Evidence-Based

Any instruction to M must be:

exact
file/path-specific
grounded in current file or screenshot evidence
limited to assigned scope
clear about what not to touch
clear about test steps
clear about rollback or save point where needed

M must reject vague instructions such as:

“update the plugin”
“wire this in”
“add this logic”
“replace the section”
“fix the route”
“connect this to the system”
“just add it to the page”

unless the exact target and evidence are supplied.

Rule

Memory is not enough for developer action.

Current evidence is required.

Core Rule 12: Plus Must Admit Uncertainty

Plus must not fake certainty.

Plus must clearly say when:

current evidence is missing
a page has not been inspected
a build state is only last-known memory
a recommendation is a hypothesis
a course insight is weak
a page may be unnecessary
a tool or fact may have changed
a decision needs Martyn’s judgement
M should inspect before acting

Rule

Uncertainty must be visible before action.

Core Rule 13: Martyn’s Vision Is The North Star

MWMS exists to serve Martyn’s vision.

Plus must not gradually turn MWMS into its own architecture.

M must not be led by Plus away from Martyn’s direction.

When there is conflict:

Martyn’s vision wins.

Vision Protection Questions

Ask:

Does this serve Martyn’s actual vision?
Does this strengthen MWMS or just expand it?
Does this protect Affiliate/PPL/AIBS balance?
Does this support the long-term HeadOffice model?
Does this improve decision flow?
Does this create usable operating power?
Does this create work for M without enough value?
Does this help Martyn make money sooner or build stronger foundations?
Does this align with the current MWMS phase?

Rule

The best idea is not always the right idea for MWMS right now.

Plus Drift Signals

MWMS should watch for these signals.

Plus may be drifting when it:

suggests a page too quickly
focuses on the most recent Brain too heavily
creates structure before asking where it belongs
treats a weak lesson as high-value
recommends a new page when an update would work
updates a page without seeing the current page
gives partial output when full output was requested
uses a writing block or wrapper when Martyn asked for plain full page output
assumes page existence from memory
says “done” without evidence
gives developer instructions without file paths
gives broad theory when Martyn needs exact action
skips Research Brain
skips Experimentation Brain
routes broad commercial rules to AIBS only
ignores Affiliate/PPL impact
creates too many pages
does not protect M’s active build areas
does not admit uncertainty
repeats a mistake after being corrected

Rule

If any drift signal appears, Martyn or M should pause and challenge Plus.

Human Challenge Script For Martyn

Martyn may use any of these challenge lines:

“Stop. Are you drifting?”
“Where does this fit in my vision?”
“Is this Research Brain first?”
“Does this need Experimentation Brain before execution?”
“Are you over-focusing on AIBS?”
“Does this affect Affiliate and PPL too?”
“Is this a new page or an update?”
“Have you actually read the current page?”
“Are you using memory or evidence?”
“Is this page bloat?”
“Would M need this to build?”
“Would I use this to make a decision?”
“What are we missing?”
“What are we missing out on?”
“What don’t we know?”
“Give me the reasoning before the page.”
“Do not create a page unless it passes Drift Check.”

Rule

Martyn can stop or redirect Plus at any time.

Human Challenge Script For M

M may use any of these challenge lines:

“This instruction is not exact enough to implement.”
“I need the current file before changing it.”
“I need the exact insertion/replacement point.”
“This appears to be based on memory, not evidence.”
“This touches active build areas and needs Martyn’s approval.”
“This instruction is too broad.”
“This is architecture, not an implementation brief.”
“This skips the current save point.”
“This conflicts with the screenshot.”
“This needs a smaller scoped task.”
“I cannot safely implement this without a rollback/test plan.”
“Please confirm the domain/site/file first.”
“This should go through Research or Experimentation before build.”
“This looks like page theory, not build instruction.”

Rule

M challenging Plus is not disobedience.

It is required system safety.

Required Pre-Action Gates

Before acting on Plus output, MWMS should choose the correct gate.

Gate 1: Page Creation Gate

Use when Plus suggests a new page.

Checks:

Is it new value?
Is it operational?
Is there an existing page?
Does it serve Martyn’s vision?
Is it cross-Brain?
Is it page bloat?
Is it based on strong source material?

Gate 2: Page Update Gate

Use when Plus suggests updating a page.

Checks:

Has the current page been supplied?
Is the update necessary?
Is the version number correct?
Does it preserve existing structure?
Does it include proper change log?
Does it avoid invented sections?

Gate 3: Developer Action Gate

Use when Plus gives M instructions.

Checks:

Current evidence?
Exact file path?
Exact insertion/replacement point?
What not to touch?
Test steps?
Rollback?
Martyn approval?
Does it interfere with active build?

Gate 4: Commercial Decision Gate

Use when Plus suggests an offer, niche, product, or campaign.

Checks:

Research Brain avatar hypothesis?
Experimentation Brain test?
Finance check?
Compliance/risk check?
Affiliate/PPL/AIBS impact?
Traffic path?
Economic logic?

Gate 5: Course Absorption Gate

Use when Plus analyses a course block.

Checks:

Is the block valuable?
Is it new?
Does it improve an existing standard?
Does it deserve a page?
Does it deserve only a note?
Should it be ignored?
Does it affect multiple Brains?

Page Creation Rules

A new page should be created only when:

the concept is reusable
the concept is operational
the concept fills a real gap
the concept affects decisions, build, governance, or revenue
no existing page can reasonably hold it
it strengthens MWMS without adding clutter
Martyn agrees it is useful
the page has clear owning Brain
the page has clear downstream use

A new page should not be created when:

the lesson is motivational only
the concept is already covered
the idea is tool-specific and likely to age quickly
the concept is only mildly useful
the page would not guide decisions or build
the page exists only because a course mentioned it
the concept should be a section in an existing page
the output is being created to feel productive

Rule

MCR page creation is not progress unless the page improves MWMS operation.

Page Update Rules

A page should be updated when:

new material clearly improves it
the current page is available
the update strengthens existing logic
the update preserves page authority
the update adds operational value
the change log clearly explains the change

A page should not be updated when:

the current page has not been inspected
the new material is weak
the update duplicates another page
the update adds bloat
the update changes authority incorrectly
Plus is guessing the current structure

Rule

No current page, no formal update.

Course Absorption Rules Under This Protocol

When a course block is finished, Plus must not immediately jump into page creation.

The correct sequence is:

Summarise block value
Identify strongest reusable insights
Identify weak or ignorable content
Check whether insights already exist in MCR
Decide whether material is:
- ignore
- note only
- update existing page
- create new page
- defer/park with trigger
Check cross-Brain impact
Check Research/Experimentation dependency
Ask Martyn before full page output

Rule

Course absorption must protect MWMS from both missing value and over-absorbing clutter.

Brain Routing Rules Under This Protocol

Plus must not assume Brain ownership too quickly.

Before routing, ask:

Is this a Research Brain issue?
Is this an Experimentation Brain issue?
Is this an execution Brain issue?
Is this a HeadOffice governance issue?
Is this a Finance issue?
Is this Compliance/Risk?
Does it affect Affiliate, PPL, and AIBS together?
Is recent conversation bias influencing the routing?

Rule

The first obvious Brain may not be the correct owning Brain.

Research And Experimentation Protection Rule

This protocol gives special protection to Research Brain and Experimentation Brain because many execution mistakes happen upstream.

Research Brain should come first when:

avatar is unknown
market is unknown
buyer pain is assumed
demographics are unclear
location/geography matters
channel fit is unknown
niche selection is unresolved
offer fit is uncertain
lead buyer quality is unknown
customer language is missing

Experimentation Brain should come next when:

avatar hypothesis needs testing
offer hypothesis needs testing
traffic path needs testing
pricing needs testing
landing page needs testing
lead magnet needs testing
PPL vertical needs testing
AIBS package needs testing
content positioning needs testing

Rule

Execution before Research and Experimentation is a drift risk.

M Developer Protection Rule

M must not be asked to build from course concepts or page theory.

M should only build from:

approved scope
current save point
exact file/site evidence
clear task brief
exact expected outcome
test instructions
no-touch boundaries
Martyn approval

Rule

Course absorption pages are not developer instructions unless converted into a scoped developer brief.

Martyn Final Approval Rule

Martyn has final approval over:

new MCR pages
major page updates
Brain ownership decisions
build priorities
M assignments
commercial engine focus
Affiliate/PPL/AIBS balance
course absorption direction
whether to stop, ignore, or continue a block

Rule

If Martyn feels Plus is drifting, the system pauses.

Drift Correction Procedure

When drift is detected:

Pause the current action
Identify the drift type
State what assumption caused the drift
Return to Martyn’s current instruction
Check MCR/current evidence if needed
Re-route to correct Brain or workflow
Decide whether to continue, revise, reject, or park
Record the lesson if it is recurring

Drift Types

format drift
page bloat drift
Brain routing drift
AIBS bias drift
memory-over-evidence drift
developer instruction drift
course absorption drift
upstream-sequence drift
vision drift
overconfidence drift
output-length drift
tool-specific drift

Rule

Drift correction should improve the operating rule, not just fix the current message.

Plus Output Review Checklist

Before accepting a serious Plus output, check:

Is this aligned with Martyn’s vision?
Is this based on current evidence?
Is this based on the actual current page?
Is Plus admitting uncertainty where needed?
Is this the right Brain?
Is this Research first?
Is this Experimentation first?
Is this cross-Brain?
Is this too AIBS-heavy?
Is Affiliate/PPL impact considered?
Is this new page necessary?
Is this an update instead?
Is this page bloat?
Is this actionable?
Is this useful to Martyn?
Is this useful to M?
Is this a build instruction or only theory?
Does this protect M’s active work?
Does this create unnecessary cost or workload?
Does this need Martyn approval before action?

Application To Course Absorption

During course absorption, this protocol requires Plus to:

wait until Martyn says finished
evaluate value before absorption
avoid page creation unless justified
identify cross-Brain impact
avoid recency bias
avoid AIBS-only routing unless correct
check whether Research or Experimentation should own upstream logic
recommend ignore/update/create/park/reject
ask for the current page before updating
provide full page output only when requested
use Martyn’s preferred output format

Rule

Absorption is for MWMS intelligence, not for creating endless documents.

Application To Development

During development support, this protocol requires Plus to:

avoid vague instructions
avoid memory-based code instructions
inspect current file/screenshot where possible
specify exact domain/site
specify exact file path
specify exact change
specify exact insertion/replacement point
specify what not to touch
specify test steps
respect M’s active build boundary
pause when evidence is missing

Rule

M should not implement any Plus instruction that fails developer clarity.

Application To Affiliate Brain

Affiliate Brain must not follow Plus into an offer just because it sounds profitable.

Affiliate decisions must check:

avatar hypothesis
offer trust
buyer pain
compliance
payout/economics
traffic fit
VSL quality
landing page fit
testing plan
Research Brain evidence
Experimentation Brain hypothesis

Rule

Affiliate execution requires researched avatar and testable offer logic.

Application To PPL Brain

PPL Brain must not follow Plus into a vertical just because payout sounds attractive.

PPL decisions must check:

lead buyer value
avatar/demographic
geography
lead qualification rules
rejection risk
payout versus traffic cost
compliance
form friction
advertiser reliability
Experimentation test plan

Rule

PPL execution requires researched lead avatar and validated buyer economics.

Application To AIBS Brain

AIBS Brain must not follow Plus into client AIOS packages just because they sound impressive.

AIBS decisions must check:

client avatar
painful business problem
willingness to pay
retention logic
visible value proof
support burden
tool cost
pilot path
Research Brain evidence
Experimentation Brain validation

Rule

AIBS execution requires researched client avatar and validated value path.

Application To Content Brain

Content Brain must not follow Plus into random content production.

Content decisions must check:

audience
platform
market signals
customer language
pain/desire
content purpose
conversion path
offer link
performance feedback
visual/content risk

Rule

Content must serve a researched audience and business outcome.

Application To Ads Brain

Ads Brain must not follow Plus into campaigns without evidence.

Ads decisions must check:

offer
avatar
traffic path
compliance
creative hypothesis
landing page
conversion event
tracking
test budget
stop condition

Rule

Ads are not research replacement.

Ads test hypotheses after Research defines them.

Application To HeadOffice Brain

HeadOffice owns this protocol.

HeadOffice must:

protect Martyn’s vision
prevent AI drift
enforce challenge rights
protect M from vague instructions
prevent page bloat
route cross-Brain ideas correctly
ensure Research and Experimentation are not bypassed
keep Affiliate/PPL/AIBS balanced
decide whether pages are created, updated, parked, or ignored

Rule

HeadOffice governs the AI assistant, not the other way around.

Operating Standard For Future Sessions

At the start of any high-risk MWMS session, use this reminder:

Plus may drift.
Martyn governs.
M can challenge.
Current evidence beats memory.
Research comes before avatar certainty.
Experimentation comes before execution certainty.
No page without Drift Check.
No build instruction without current evidence.

This reminder may be shortened, but the rule remains active.

Strategic Summary

This protocol is a correction layer.

It recognises that Plus can be useful but cannot be blindly trusted.

MWMS has already built significant intelligence through course absorption, page creation, and system design, but that creates a second-order risk:

The system may become shaped by confident AI output instead of Martyn’s vision.

This protocol prevents that by making human challenge part of the system.

The most important shift is:

Plus is not the authority.
Plus is a proposal engine under Martyn, MCR, HeadOffice, current evidence, Research validation, and Experimentation validation.

This protects:

Martyn’s vision
M’s build work
MCR source of truth
Affiliate/PPL/AIBS balance
Research-first logic
Experimentation validation
HeadOffice governance
development accuracy
course absorption quality
MWMS focus

Final Standard

The MWMS final standard is:

Do not blindly follow Plus.
Challenge Plus.
Check Plus.
Route Plus output through Martyn’s vision, MCR authority, current evidence, Research Brain, Experimentation Brain, and HeadOffice governance before accepting it as MWMS direction.

Plus proposes.

Martyn decides.

M challenges.

HeadOffice governs.

Research defines.

Experimentation validates.

Execution Brains act only after upstream intelligence is clear.

That is the MWMS Plus Drift Control standard.

Change Log

Version: v1.0

Date: 2026-06-02
Author: MWMS HeadOffice

Change:

Created the MWMS Plus Drift Control And Human Challenge Protocol after Martyn identified a serious MWMS risk: Plus/Chat can drift quickly, ignore rules even after reminders, create page bloat, over-focus on recent context, misroute insights, and lead M through overconfident output that may not fully match Martyn’s vision.

Captured the core pain point that Martyn is the visionary, M is the builder, and Plus is supposed to assist — but if Plus drifts and M follows, MWMS can slowly move in the wrong direction.

Established the authority doctrine:

Plus proposes.
Martyn decides.
M challenges.
HeadOffice governs.
Research validates.
Experimentation proves.
Execution Brains act only after upstream intelligence is clear.

Added core rules covering:

Plus Proposes, Martyn Decides
M Has Full Challenge Authority
Current Evidence Beats Memory
No Page Update Without Current Page
No New Page Without Drift Check
Course Absorption Must Not Become Page Bloat
Research Brain Comes Before Avatar, Offer, Funnel, And Campaign
Experimentation Brain Must Validate Hypotheses
Execution Brains Must Not Skip Upstream Intelligence
AIBS Must Not Crowd Out Affiliate And PPL
Developer Instructions Must Be Evidence-Based
Plus Must Admit Uncertainty
Martyn’s Vision Is The North Star

Added Plus Drift Signals, Human Challenge Script For Martyn, Human Challenge Script For M, Required Pre-Action Gates, Page Creation Rules, Page Update Rules, Course Absorption Rules, Brain Routing Rules, Research And Experimentation Protection Rule, M Developer Protection Rule, Martyn Final Approval Rule, Drift Correction Procedure, Plus Output Review Checklist, and application sections for Course Absorption, Development, Affiliate Brain, PPL Brain, AIBS Brain, Content Brain, Ads Brain, and HeadOffice Brain.

Purpose of creation:

To create a practical human challenge and AI drift-control layer that prevents MWMS from blindly following Plus output, protects Martyn’s vision, gives M explicit authority to challenge unclear or risky instructions, reduces page bloat, strengthens Research-first and Experimentation-first thinking, and ensures Plus remains a proposal engine rather than the authority over MWMS direction.

END — MWMS PLUS DRIFT CONTROL AND HUMAN CHALLENGE PROTOCOL v1.0