MWMS MCR To Brain Copy Rule

Document Type: Standard
Status: Active
Authority: HeadOffice
Applies To: All MWMS Brains, MCR Content, Brain Site, Future UI/Plugin Systems
Primary MCR Location: HeadOffice
Primary Operational Destination: mwmsbrain.site
Version: v1.1
Last Reviewed: 2026-05-11

Purpose

The MWMS MCR To Brain Copy Rule defines how approved content moves from the MCR into downstream MWMS operating environments.

This includes:

Brain environments
mwmsbrain.site
mwmsheadofficebrain.site
future Brain-specific sites
plugin systems
UI interfaces
operational tools
Supabase-connected execution systems

This rule prevents:

duplication
unnecessary copying
structural confusion
broken source of truth
wasted build effort
accidental canon drift
operational systems rewriting governance

MCR remains the central intelligence, structure, and governance layer.

Brain sites and plugin systems may use MCR-approved content, but they do not replace MCR authority.

Scope

This rule applies to:

all MCR pages
all Brain pages
all Brain copy maps
all Brain operating pages
all plugin specifications
all UI specifications
all dashboard specifications
all task execution specifications
all Supabase-connected operating systems
all future Brain site deployments

This rule applies whenever content is being considered for:

staying in MCR only
being copied to a Brain site
being transformed for Brain site use
being converted into plugin/UI functionality
being referenced by automation
being suggested for canon update after live use

Core Principle

MCR is always the Source of Truth.

No Brain site, UI, plugin, dashboard, automation, or Supabase-connected system owns the original version of any canon page, governance rule, standard, framework, registry, or architecture definition.

All downstream systems may:

consume MCR content
display MCR-approved content
operationalise MCR-approved content
execute workflows based on MCR-approved content
generate feedback from live use
suggest improvements for review

But they must not:

replace MCR authority
overwrite MCR canon
directly edit MCR pages
promote operational learning into canon without review
create competing source-of-truth versions

Direction Of Authority

The approved direction of authority is:

MCR → Brain Site → Plugin/UI/Supabase Execution

The reverse direction is not automatic.

The Brain site may generate operational feedback, but that feedback must move through HeadOffice before it can affect MCR.

The approved feedback path is:

Brain Site → HeadOffice Review → MCR Decision

The prohibited path is:

Brain Site → Direct MCR Update

Brain sites are allowed to report learning.

Brain sites are not allowed to rewrite canon.

Definition Of MCR

MCR is the MWMS Source of Truth environment.

It stores:

canon pages
governance standards
architecture definitions
Brain structures
copy maps
page registries
operating rules
cross-Brain protocols
decision authority structures
system-level frameworks
approved build instructions

MCR defines what the system is, how the system is structured, and what rules downstream systems must follow.

Definition Of Brain Site

A Brain site is an operational environment where approved MWMS knowledge is used to support real work.

Brain sites may include:

operational Brain pages
simplified working versions of frameworks
workflow pages
intake screens
task views
dashboard screens
employee interfaces
Brain Room systems
Supabase-connected tools
plugin-driven operating surfaces

A Brain site is not the Source of Truth.

A Brain site is a working environment.

Three Destination Types

Every MCR page must be classified into one of three destination types.

1. MCR Only

The page remains inside MCR and is not copied elsewhere.

This classification is used for:

governance rules
canon pages
system standards
architecture definitions
decision authority structures
page naming rules
parent map rules
AI output standards
source-of-truth rules
system-wide protocols

These pages are:

read-only references
governance controls
structural authority pages
not operational tools
not daily workflow screens

Examples

MWMS Page Naming Standard
MWMS Document Structure Standard
MWMS Canon Session Protocol
MWMS Brain Routing Rule
MWMS AI Output Standard Full File Delivery Rule
MWMS Architecture Registry
MWMS Authority Structure

2. Copy To Brain

The page is copied or transformed into a Brain environment.

This classification is used for:

operational workflows
structured evaluation pages
repeat-use frameworks
decision-support tools
operating models
intake workflows
execution guides
handoff processes
working instructions

These pages are:

actively used by operators
part of daily workflow
suitable for simplified working versions
derived from MCR
still governed by MCR

The Brain version is a working copy.

The MCR version remains canonical.

Examples

Affiliate Brain Offer Intelligence
Affiliate Brain Opportunity Intake Workflow
Research Brain Signal Classification Framework
Research Brain Test Learning And Signal Capture Framework
Experimentation Brain Test Result And Decision Workflow
Finance Brain Test Budget And Capital Control Specification
Content Brain Workflow Map
Content Brain Operating Model

3. Later Plugin Or UI

The page should not be manually copied as a normal working page.

Instead, it should later become:

a UI screen
a plugin feature
a dashboard
a task system
an intake form
a registry interface
an automation workflow
a Supabase-powered operating surface

This classification is used for:

dashboards
intake forms
registries
tracking systems
automation flows
signal logging
task execution
repeatable structured input/output systems

These pages may begin as MCR specifications, but their long-term destination is functional system build.

Examples

Affiliate Brain Opportunity Queue
HeadOffice Page Registry
HeadOffice Newsletter Intelligence Dashboard Specification
MWMS Opportunity Intake Phase One Developer Build Pack
MWMS Opportunity System Implementation Brief For M
HeadOffice Cross Brain Performance And Control Dashboard Specification
Affiliate Brain Intake Screen Specification
Experimentation Brain Test Candidate Screen Specification

Classification Rule

Every page being considered for downstream use must be assigned the following fields:

Field	Required Value
Destination	MCR Only / Copy To Brain / Later Plugin Or UI
Reason	Governance / Operational / Automation / UI / Tracking
Source Of Truth	Always MCR
Operational Destination	Brain Site / Plugin / UI / Supabase / None
Review Authority	HeadOffice
Update Direction	MCR To Brain / Brain Feedback To HeadOffice

No page should be copied or operationalised without classification.

Decision Logic

Use this logic when classifying pages.

If The Page Defines Rules → MCR Only

Examples:

naming standards
canon protocols
authority structures
governance rules
AI output rules
source-of-truth rules
document structure standards

These pages stay in MCR.

They may be referenced by Brain sites, but they are not copied as working tools unless HeadOffice approves a simplified reference version.

If The Page Is Used Regularly By A Human → Copy To Brain

Examples:

offer evaluation
research workflows
decision frameworks
testing processes
operating models
review workflows
handoff guides

These pages may be copied to the relevant Brain site as working pages.

They may be simplified for usability, but their logic must remain aligned with MCR.

If The Page Involves Repeated Structured Interaction → Later Plugin Or UI

Examples:

intake forms
dashboards
registries
tracking tables
status boards
reporting systems
task queues
signal logs
Brain Room request screens

These pages should become plugin/UI systems rather than manually maintained pages.

Transformation Rule

When copying a page from MCR to a Brain site:

simplify structure if needed
remove governance-only sections if they do not help the operator
keep operational logic intact
keep decision rules intact
keep handoff rules intact
keep authority notes where needed
make the page usable for real workflows
avoid unnecessary canon language where it slows operation

The Brain version must clearly remain a working version.

It must not present itself as the canonical source.

Brain Working Copy Rule

A Brain site page may be a simplified or operationalised version of an MCR page.

However:

the MCR page remains the master version
the Brain page must not contradict the MCR page
the Brain page must not introduce unapproved authority
the Brain page must not create a competing standard
the Brain page must not silently change workflow logic
any improvement must be routed back through HeadOffice

Brain pages exist to support work.

MCR pages exist to define authority.

MCR To Brain Update Rule

When an MCR page is updated, HeadOffice may decide whether the update should flow into the relevant Brain site.

This can happen when:

the update affects an operational workflow
the update changes a decision rule
the update changes a required field
the update changes handoff logic
the update changes dashboard requirements
the update changes task routing
the update affects plugin or UI behaviour

Not every MCR update must be copied to Brain.

Only updates with operational impact should be pushed downstream.

Brain Site Feedback Rule

Brain sites may generate feedback from real use.

This feedback may include:

unclear workflow steps
missing fields
repeated operator confusion
task execution issues
plugin/UI friction
dashboard gaps
decision logic conflicts
evidence from live testing
suggested improvements
proposed new operating rules

This feedback must not directly update MCR.

It must be routed to HeadOffice for review.

Approved path:

Brain Site Feedback → HeadOffice Review → MCR Update Decision

HeadOffice may then decide to:

approve the change
reject the change
park the change
request more evidence
update an MCR page
create a new MCR page
update a Copy Map
update a Plugin/UI specification
route the issue to another Brain

Brain To MCR Direct Update Ban

No Brain site, plugin, UI, automation, employee, or Supabase process may directly update MCR canon.

This prevents:

accidental canon corruption
unapproved rule changes
conflicting versions
operational shortcuts becoming system law
automation-driven drift
Brain-level bias changing HeadOffice authority

Any proposed MCR update must pass through HeadOffice.

HeadOffice Review Authority

HeadOffice is the review and approval layer for all Brain-to-MCR feedback.

HeadOffice decides whether operational learning becomes:

canon update
governance update
copy map update
system architecture update
plugin/UI change
dashboard change
task schema change
parked insight
rejected suggestion

HeadOffice must protect the Source of Truth while still allowing the MWMS ecosystem to learn from live use.

No Blind Copy Rule

Pages must not be copied:

without classification
without a defined use case
without a clear operator benefit
without checking for duplicates
without knowing the correct destination
without understanding whether it should become UI/plugin instead
without confirming MCR remains Source of Truth

Blind copying leads to:

duplication
confusion
system bloat
broken workflows
outdated Brain pages
unnecessary developer work
unclear authority

Example Classification

Page	Destination	Reason
MWMS Page Naming Standard	MCR Only	Governance
MWMS Document Structure Standard	MCR Only	Governance
MWMS Architecture Registry	MCR Only	System Architecture
Affiliate Brain Offer Intelligence	Copy To Brain	Operational
Affiliate Brain Opportunity Intake Workflow	Copy To Brain	Operational Workflow
Research Brain Signal Classification Framework	Copy To Brain	Operational Research Support
Experimentation Brain Test Result And Decision Workflow	Copy To Brain	Operational Testing Workflow
Finance Brain Test Budget And Capital Control Specification	Later Plugin Or UI	Structured Control System
Affiliate Brain Opportunity Queue	Later Plugin Or UI	Task/Queue Automation
HeadOffice Page Registry	Later Plugin Or UI	System Tracking
HeadOffice Newsletter Intelligence Dashboard Specification	Later Plugin Or UI	Dashboard Build
MWMS Opportunity Intake Phase One Developer Build Pack	Later Plugin Or UI	Developer Build Instruction

System Flow

The approved system flow is:

Page is created or updated in MCR.
Page is classified using this rule.
Destination is assigned.
If MCR Only:
- page remains in MCR.
If Copy To Brain:
- page is copied or transformed into the relevant Brain site.
If Later Plugin Or UI:
- page is used as a build specification.
Brain site uses the approved working version.
Plugin/UI/Supabase systems execute approved workflows.
Brain site generates operational feedback if needed.
Feedback routes to HeadOffice.
HeadOffice decides whether MCR should be updated.
MCR remains Source of Truth.

Approved Direction Map

Direction	Allowed?	Rule
MCR → Brain Site	Yes	Approved through copy map or HeadOffice decision
MCR → Plugin/UI Specification	Yes	Approved through build specification
MCR → Supabase Execution Logic	Yes	Approved through schema/task specification
Brain Site → HeadOffice Feedback	Yes	Allowed as suggestion or operational signal
Brain Site → MCR Direct Update	No	Prohibited
Plugin/UI → MCR Direct Update	No	Prohibited
Supabase Automation → MCR Direct Update	No	Prohibited
HeadOffice → MCR Update	Yes	Approved authority path

Validation Checklist

Before copying any page to a Brain site, confirm:

destination is clearly defined
real use case exists
no duplicate already exists
page is not governance-only
correct Brain destination is known
correct parent page is known
transformation requirement is understood
page title follows naming standard
Brain page will not claim canon authority
MCR remains the Source of Truth
HeadOffice has authority over future updates

Brain Site Readiness Checklist

Before expecting a Brain site to do useful work, confirm it has:

relevant operating pages
relevant workflow pages
relevant handoff instructions
relevant screen specifications
relevant task instructions
relevant dashboard specifications
relevant Supabase schema references
relevant copy maps
clear limits on what it can and cannot change
a feedback path back to HeadOffice

A Brain site without approved operational content is only a container.

A Brain site becomes useful when MCR-approved operating knowledge is copied, transformed, or built into it.

Common Errors This Prevents

This rule prevents:

copying every MCR page into Brain sites
creating duplicate source-of-truth pages
mixing governance with operations
building UI before understanding usage
losing track of canonical authority
allowing Brain sites to rewrite MCR
allowing plugins to become hidden authority layers
allowing Supabase processes to create unapproved system rules
confusing working copies with canon pages
making M’s development work harder through unclear instructions

Governance Role

This rule protects the separation between:

MCR authority
Brain site operation
plugin/UI execution
Supabase data handling
HeadOffice approval

It ensures that MWMS can scale without losing structural control.

The purpose is not to slow work down.

The purpose is to make sure the work is copied, built, and improved in the right direction.

Relationship To Other MWMS Standards

This rule works alongside:

MWMS Page Naming Standard
MWMS Page Parent Map
MWMS Document Structure Standard
MWMS Brain Build Order Standard
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Brain Connector Architecture
MWMS Standard Cross Brain Flow
MWMS Supabase Task Schema Standard
MWMS Plugin Build Instruction Standard
MWMS AI Output Standard Full File Delivery Rule

Where conflicts appear, HeadOffice must decide the correct governing rule before copying or building.

Drift Protection

This rule protects against drift by enforcing:

MCR as Source of Truth
classified destinations
no blind copying
no Brain-to-MCR direct updates
HeadOffice review for all suggested canon changes
working copies clearly separated from canonical pages
plugin/UI systems treated as execution layers, not authority layers

No downstream system may become the hidden Source of Truth.

Architectural Intent

The architectural intent is:

MCR writes the law. Brain sites do the work. HeadOffice decides what learning becomes law.

MCR must remain clean, structured, and authoritative.

Brain sites must be practical, usable, and operational.

Plugin/UI systems must make repeatable workflows easier.

Supabase must store and execute approved system logic.

HeadOffice must control what becomes canon.

Final Rule

If unsure:

Default to MCR Only.

Then classify later when usage becomes clear.

No page should move downstream unless there is a clear operational reason.

No Brain site feedback should move upstream unless HeadOffice reviews it.

No MCR canon should be changed directly by a Brain site, plugin, UI, or automation.

Status

This is the official rule for all MCR to Brain content movement.

All future copy decisions must follow this structure.

All Brain-site feedback must route through HeadOffice before any MCR page is changed.

Change Log

v1.0 — 2026-04-24

Initial rule created to define MCR Only, Copy To Brain, and Later Plugin Or UI classifications.

v1.1 — 2026-05-11

Expanded rule to define:

MCR to Brain authority direction
Brain Site feedback pathway
Brain to MCR direct update ban
HeadOffice review authority
Brain Site readiness requirements
approved direction map
stronger drift protection for Brain sites, plugin systems, UI systems, and Supabase execution.