Document Type: Protocol
Status: Canon
Version: v1.2
Authority: MWMS HeadOffice
Applies To: All MWMS Brains, HeadOffice, MCR, Brain Sites, WordPress control surfaces, Supabase request records, plugin/UI systems, task execution systems, Brain Room, and cross-Brain request handling
Parent: Governance
Last Reviewed: 2026-05-11
Purpose
The MWMS Brain To Brain Request Protocol defines how Brains within MWMS must communicate with one another.
Its purpose is to ensure that all cross-Brain communication is:
- structured
- traceable
- governed
- reviewable
- lineage safe
- reusable across the ecosystem
- visible to HeadOffice where required
Brains must not communicate through informal notes, hidden logic, direct plugin coupling, ad hoc shortcuts, untracked field changes, or private system-to-system assumptions.
MWMS requires a formal request structure so that intelligence, decisions, actions, and work handoffs remain visible across the system.
This protocol exists to:
- prevent informal Brain-to-Brain communication drift
- create a standard handoff structure across all Brains
- preserve request lineage from origin to outcome
- ensure HeadOffice visibility over important cross-Brain movement
- support Supabase-backed request and task tracking
- support WordPress and Brain-site workspace visibility
- support future plugin/UI execution surfaces
- support Brain Room request handling
- prevent Brain requests from becoming unapproved canon changes
- support future scaling of MWMS without communication chaos
This protocol converts cross-Brain communication into a governed system process.
This protocol operates in conjunction with:
- MWMS Brain System Map
- MWMS Brain Interaction Map
- MWMS Brain Connector Architecture
- MWMS MCR Brain Wiring Map
- MWMS MCR To Brain Copy Rule
These pages provide structural visibility, authority control, and connector logic for how Brains relate, communicate, and return outcomes.
Source page provided for update:
Scope
This protocol applies to:
- all Brain-to-Brain requests inside MWMS
- requests moving between Research Brain, Affiliate Brain, Ads Brain, Experimentation Brain, Finance Brain, SIT Brain, AIBS Brain, Content Brain, HeadOffice Brain, and future Brains
- Brain site to HeadOffice feedback requests
- HeadOffice visibility over cross-Brain requests
- WordPress request intake and workspace views
- Supabase request and task lineage records
- request status progression
- escalation and review points
- cross-Brain request outcomes
- decision recording
- result return logic
- Brain Room message-to-request workflows
- plugin/UI task handoff systems
- structured feedback that may require HeadOffice review
This protocol governs how Brains:
- initiate requests
- pass requests
- receive requests
- review requests
- respond to requests
- escalate requests
- close requests
- return results
- submit operational feedback
This protocol does not govern:
- Brain internal working logic by itself
- detailed UI design by itself
- full Supabase schema implementation by itself
- task executor implementation by itself
- Brain authority boundaries by themselves
- final capital approval by itself
- MCR canon editing by itself
Those remain governed by:
- MWMS Brain Canon documents
- MWMS System Architecture
- MWMS System Data Flow Map
- MWMS Brain Interaction Map
- MWMS Brain Connector Architecture
- MWMS MCR To Brain Copy Rule
- MWMS MCR Brain Wiring Map
- MWMS Supabase Naming Standard
- MWMS PHP Build And Modularity Standard
- Finance Brain governance
- SIT Brain governance
- HeadOffice governance
- MCR canon authority rules
Core Principle
Brains do not communicate through informal conversation.
Brains communicate through structured requests.
All cross-Brain communication must be:
- declared
- stored
- visible
- traceable
- reviewable
- governable
- status driven
- outcome based
The canonical communication chain is:
Brain Request
↓
Review / Routing
↓
Task / Workspace Visibility
↓
Decision / Response
↓
Status / Outcome
↓
HeadOffice Visibility
↓
Escalation If Required
↓
MCR Decision Only If HeadOffice Approves
This aligns with MWMS system architecture, where work moves through structured requests, tasks, events, outputs, and review pathways rather than informal tool-to-tool chatter.
Source Of Truth Rule
Brain-to-Brain requests do not create canon.
Brain-to-Brain communication may generate:
- findings
- recommendations
- warnings
- decisions
- task outcomes
- operational feedback
- escalation requests
- suggested improvements
But it must not directly update MCR.
MCR remains the Source of Truth for:
- canon
- governance
- architecture
- Brain structures
- standards
- copy maps
- authority rules
- system rules
The approved feedback path is:
Brain Request / Brain Site Feedback → HeadOffice Review → MCR Decision
The prohibited path is:
Brain Request → Direct MCR Update
No Brain, Brain site, plugin, UI, automation, task executor, or Supabase process may directly rewrite MCR canon.
Rule 1 — No Direct Brain To Brain Informal Messaging
No Brain may privately communicate with another Brain through:
- hidden plugin logic
- hard-coded custom one-off calls
- freeform notes as the primary contract
- untracked field mutations
- non-visible local-only handoffs
- informal status assumptions
- private chat-style dependencies
- undocumented automation shortcuts
All Brain-to-Brain communication must use the formal request structure defined by this protocol.
Rule 2 — Structured Request Requirement
Every cross-Brain communication must be represented as a formal Brain Request.
A valid Brain Request must contain, at minimum:
- origin_brain
- destination_brain
- request_type
- request_title
- request_summary
- request_status
- priority
- lineage identifiers
- created_at
- updated_at
Where relevant, lineage identifiers must include:
- intake_id
- offer_id
- task_id
- source_origin
- parent_request_id
- originating_task_id
Additional request detail may be stored in structured payload fields where needed.
Rule 3 — HeadOffice Visibility Requirement
HeadOffice must have visibility into cross-Brain requests.
This does not mean HeadOffice must manually intervene in every request.
It means the system must ensure that Brain-to-Brain requests are:
- visible to HeadOffice
- reviewable if needed
- escalate-able where appropriate
- aligned to MWMS-wide system good rather than local Brain convenience
- available for audit if risk, capital, compliance, architecture, or canon authority is involved
Cross-Brain communication must never become a hidden subsystem beyond HeadOffice awareness.
Rule 4 — Request Lineage Preservation
Every Brain Request must preserve lineage.
If a request originates from an intake, opportunity, offer, task, signal, Brain Room message, prior request, plugin event, or Supabase record, that linkage must remain visible.
Examples of lineage fields include:
- intake_id
- offer_id
- parent_request_id
- originating_task_id
- source_origin
- source_page
- source_system
- related_task_ids
- related_event_ids
Lineage must not be lost during:
- routing
- list rendering
- workspace opening
- Brain handoff
- decision recording
- result return
- escalation
- closure
If lineage is lost, the request becomes structurally weak and auditability is reduced.
Rule 5 — Standard Request Status Flow
All Brain Requests must move through a defined status model.
Minimum standard statuses:
- new
- under_review
- routed
- in_progress
- responded
- escalated
- closed
- blocked
Optional additional statuses may include:
- parked
- rejected
- awaiting_evidence
- awaiting_head_office_review
- awaiting_mcr_decision
- returned_for_revision
Brains may use narrower child-stage logic inside their own workspaces, but they must not break the core request status model without explicit governance approval.
Rule 6 — Standard Request Roles
Each Brain Request must make role ownership clear.
Minimum ownership roles:
- origin owner
- destination owner
- review owner
- escalation owner where required
- result owner where required
In default MWMS operation:
| Role | Default Owner |
|---|---|
| Origin Owner | Requesting Brain |
| Destination Owner | Receiving Brain |
| Review Owner | HeadOffice or designated Brain workspace logic |
| Escalation Owner | HeadOffice, SIT, Finance, Compliance, Risk, or other authority depending on request type |
| Result Owner | Brain responsible for returning the outcome |
Ownership must be visible.
No request should depend on assumed ownership.
Rule 7 — Request Outcome Requirement
A Brain Request must not simply disappear after action.
Each request must end in a visible outcome state.
Minimum outcome types may include:
- recommendation delivered
- decision recorded
- routed onward
- blocked
- escalated
- closed without action
- rejected
- parked for later
- awaiting further evidence
- HeadOffice review required
- MCR update suggested
A request without an outcome is incomplete.
“Done” is not a sufficient governed outcome.
A valid outcome must explain:
- what was requested
- what was completed or found
- what decision was made
- what evidence supports the decision
- what happens next
- who owns the next step
- whether HeadOffice review is required
Rule 8 — HeadOffice Opinion And Intervention Rule
Some requests require HeadOffice opinion for the good of MWMS.
Examples include:
- strategic disagreement between Brains
- requests affecting capital exposure
- requests affecting governance or integrity
- requests affecting system architecture
- requests affecting MCR canon
- requests involving conflicting Brain authority
- requests with unclear ownership
- requests that materially affect MWMS direction
- repeated task failures
- major workflow friction
- compliance or risk escalation
- SIT structural warnings
The system must support HeadOffice intervention without breaking request lineage.
HeadOffice intervention must attach to the existing request chain.
It must not create a disconnected side decision.
Rule 9 — Relationship To Brain Interaction Map
The Brain Interaction Map defines the structural visibility layer of MWMS Brain relationships.
The Brain To Brain Request Protocol defines the communication mechanism used when movement occurs between Brains.
The Interaction Map shows:
- which Brains may hand off to which Brains
- which Brains support which other Brains
- where oversight relationships exist
This protocol defines:
- how those handoffs occur
- what must be recorded
- how status moves
- how results return
- how escalation works
Both layers must remain aligned.
Rule 10 — WordPress And Supabase Separation Rule
WordPress acts as the control and visibility layer.
Supabase acts as the structured system-of-record layer.
Therefore:
WordPress may:
- display Brain Requests
- provide workspace visibility
- enable structured review interfaces
- show status
- show task lists
- show Brain Room request surfaces
- show result summaries
Supabase stores:
- request structure
- lineage
- status progression
- request history
- task records
- event records
- result records
- escalation records
- feedback records
This separation follows MWMS architecture discipline.
WordPress is not the canonical data store for request lineage unless explicitly approved.
Supabase supports system memory and execution visibility.
MCR remains canonical authority for rules and structure.
Rule 11 — Naming Discipline Rule
All Supabase technical objects used to implement this protocol must follow MWMS naming authority:
- lowercase only
- snake_case only
- stable descriptive names
- no casual renaming
- no mixed naming conventions
This applies to:
- tables
- columns
- views
- functions
- policies
- indexes
- triggers
- status values where possible
Naming discipline protects future automation, reporting, and developer continuity.
Rule 12 — First Implementation Principle
The first implementation must be:
- real
- useful
- narrow
- traceable
- extensible
The correct sequence is:
small implementation
↓
measured use
↓
observed weakness
↓
refinement
↓
standardisation across more Brains
Avoid premature over-engineering.
The first implementation should prove the request chain works before trying to automate every Brain relationship.
Rule 13 — Brain Feedback Is Not Canon
A Brain may identify that a workflow, field, dashboard, plugin, or operating page needs improvement.
That feedback may be submitted as a structured request.
However, Brain feedback is not canon.
Feedback must be classified by HeadOffice as one of:
- approve
- reject
- park
- investigate
- route to another Brain
- update Brain working copy
- update plugin/UI specification
- update Supabase schema
- propose MCR update
- no action required
Only approved HeadOffice decisions may change MCR.
Rule 14 — Plugin/UI Systems Must Use Requests
Plugin and UI systems must not bypass this protocol when triggering cross-Brain work.
If a plugin or UI action causes another Brain to act, the system must create or update a structured Brain Request.
Examples:
- intake form triggers Affiliate Brain review
- Affiliate review triggers Research Brain task
- Experimentation result triggers Finance review
- dashboard alert triggers HeadOffice escalation
- Brain Room message triggers task execution
The user may experience the action through a simple interface, but the system behind it must preserve request structure and lineage.
Rule 15 — Supabase Tasks Are Subordinate To Brain Requests
Supabase tasks support execution.
They do not replace Brain Requests.
The correct hierarchy is:
Brain Request = parent object
Task = execution object
Result = return object
Event = status/history object
A task without request context may be useful for local execution, but it is not a governed cross-Brain request.
Where cross-Brain work is involved, task records must preserve request lineage.
Minimum Standard Brain Request Format
Minimum required fields:
- request_id
- origin_brain
- destination_brain
- request_type
- request_title
- request_summary
- request_status
- priority
- intake_id
- offer_id
- parent_request_id
- source_origin
- source_page
- source_system
- routing_notes
- response_summary
- outcome_type
- head_office_visible
- escalation_flag
- review_owner
- escalation_owner
- related_task_ids
- feedback_required
- mcr_update_suggested
- mcr_update_status
- created_at
- updated_at
Additional fields may be added where required.
Standard Request Types
Standard request types may include:
- research_request
- offer_review_request
- experimentation_request
- finance_review_request
- ads_signal_request
- compliance_review_request
- risk_review_request
- sit_integrity_request
- content_support_request
- data_validation_request
- dashboard_update_request
- plugin_ui_build_request
- brain_room_request
- head_office_review_request
- mcr_update_suggestion
- escalation_request
Request types must remain descriptive and stable.
Practical Interpretation
Research Brain does not message Affiliate Brain directly.
Research Brain creates a Brain Request.
Affiliate Brain receives the request in its workspace.
The request remains visible to HeadOffice.
The outcome is recorded.
Lineage remains intact.
If the result suggests a change to MCR, the request must be routed to HeadOffice review.
No Brain directly updates MCR.
This is the MWMS standard communication model.
Standard Flow Example 1 — Research Brain To Affiliate Brain
Research Brain identifies a possible opportunity signal.
A Brain Request is created with:
- origin_brain = Research Brain
- destination_brain = Affiliate Brain
- request_type = offer_review_request
- source_origin = research_signal
- priority = assigned based on signal quality
Affiliate Brain reviews the opportunity.
Affiliate Brain returns:
- recommendation
- verdict
- next step
- evidence summary
- outcome type
HeadOffice remains able to view the chain.
Standard Flow Example 2 — Affiliate Brain To Experimentation Brain
Affiliate Brain approves an offer as a test candidate.
A Brain Request is created with:
- origin_brain = Affiliate Brain
- destination_brain = Experimentation Brain
- request_type = experimentation_request
- offer_id = linked offer
- intake_id = linked intake where relevant
Experimentation Brain defines the test structure.
Result returns to Affiliate Brain and HeadOffice visibility is preserved.
Standard Flow Example 3 — Experimentation Brain To Finance Brain
Experimentation Brain identifies a signal that may justify increased budget.
A Brain Request is created with:
- origin_brain = Experimentation Brain
- destination_brain = Finance Brain
- request_type = finance_review_request
- source_origin = experiment_result
- escalation_flag = true if capital exposure is material
Finance Brain evaluates exposure.
Finance Brain returns:
- approval
- rejection
- risk classification
- budget limit
- pacing condition
- escalation if required
Standard Flow Example 4 — Brain Site Feedback To HeadOffice
A Brain site identifies that an operating page, workflow, screen, or task structure is causing friction.
A Brain Request or Feedback Request is created with:
- origin_brain = relevant Brain
- destination_brain = HeadOffice
- request_type = head_office_review_request or mcr_update_suggestion
- source_origin = brain_site_feedback
- mcr_update_suggested = true or false
HeadOffice reviews the request.
HeadOffice decides whether to:
- approve change
- reject change
- park insight
- route to another Brain
- update working copy
- update MCR
- update plugin/UI specification
- request more evidence
Brain site does not directly update MCR.
Standard Flow Example 5 — Brain Room To Brain Request
A Brain Room message may trigger a structured request.
The Brain Room interface may capture:
- user instruction
- source context
- requested Brain
- urgency
- task type
- expected output
The connector layer converts this into a governed Brain Request.
The request then follows normal routing, execution, result, and closure logic.
Brain Room is an input surface.
It is not a replacement for the request protocol.
Governance Role
This protocol ensures:
- HeadOffice maintains visibility over important cross-Brain movement
- Brains communicate through structured requests
- request lineage remains preserved
- results return to their origin
- tasks do not become disconnected
- WordPress displays do not replace Supabase lineage
- plugin/UI actions do not bypass governance
- Brain-site feedback is captured safely
- MCR remains Source of Truth
- MWMS scales without communication chaos
Relationship To Other MWMS Standards
This protocol works alongside:
- MWMS Brain System Map
- MWMS Brain Interaction Map
- MWMS Brain Connector Architecture
- MWMS MCR Brain Wiring Map
- MWMS MCR To Brain Copy Rule
- MWMS Standard Cross Brain Flow
- MWMS Supabase Task Schema Standard
- MWMS Supabase Naming Standard
- MWMS System Data Flow Map
- MWMS Brain Routing Rule
- MWMS Task Architecture Standard
- MWMS Task Types Standard
- MWMS Plugin Build Instruction Standard
Where conflict appears, HeadOffice must resolve the governing rule before implementation.
Drift Protection
The system must prevent:
- informal cross-Brain messaging
- hidden logic handoffs
- loss of request lineage
- untracked decision flow
- non-visible cross-Brain state changes
- duplicate communication patterns
- one-off connector shortcuts
- loss of HeadOffice visibility
- plugin/UI systems bypassing requests
- Supabase tasks replacing Brain Requests
- Brain feedback becoming unapproved canon
- Brain sites directly updating MCR
Cross-Brain communication must remain governed.
Architectural Intent
MWMS operates as a multi-Brain architecture.
Communication discipline ensures:
- traceability
- auditability
- scalability
- governance visibility
- structural clarity
- controlled execution
- safe feedback
- HeadOffice oversight
The Brain Interaction Map provides structural visibility.
The Brain Connector Architecture provides movement and transport logic.
The Brain To Brain Request Protocol provides operational communication discipline.
Together they ensure MWMS scales without communication chaos.
Final Rule
Brains may request.
Brains may route.
Brains may respond.
Brains may escalate.
Brains may generate feedback.
Brains may suggest improvements.
But Brains may not directly rewrite MCR canon.
All proposed MCR changes must pass through:
HeadOffice Review → MCR Decision
Change Log
v1.1 — 2026-04-10
Added explicit alignment with MWMS Brain System Map and MWMS Brain Interaction Map.
Clarified separation between:
- structural relationship visibility layer
- communication protocol layer
Improved readiness for start stack inclusion.
v1.2 — 2026-05-11
Expanded protocol to align with updated:
- MWMS MCR To Brain Copy Rule
- MWMS MCR Brain Wiring Map
- MWMS Brain Connector Architecture
Added:
- Source Of Truth Rule
- Brain feedback is not canon rule
- plugin/UI request rule
- Supabase tasks subordinate to Brain Requests rule
- Brain site feedback to HeadOffice flow
- Brain Room to Brain Request flow
- MCR direct-update prohibition
- additional request fields for feedback and MCR update suggestions
- stronger drift protection for Brain sites, plugin/UI systems, and Supabase execution
Change Impact Declaration
Pages Updated:
MWMS Brain To Brain Request Protocol
Pages Created:
None
Pages Deprecated:
None
Registries Requiring Update:
None
Canon Version Update Required:
No
Monthly Change Log Entry Required:
Optional — only required if HeadOffice wants this protocol expansion recorded in the current MWMS System Change Log.