MWMS MCR

MWMS Brain to Brain Request Protocol

Document Type: Protocol
Status: Canon
Version: v1.0
Authority: MWMS HeadOffice
Applies To: All MWMS Brains, HeadOffice, WordPress control surfaces, Supabase request records, and cross-brain request handling
Parent: Governance
Last Reviewed: 2026-03-27

Purpose

This 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
  • reusable across the ecosystem

Brains must not communicate through informal notes, hidden logic, direct plugin coupling, or ad hoc system shortcuts.

MWMS requires a formal request structure so that intelligence, decisions, 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 future scaling of MWMS without communication chaos

This protocol converts cross-brain communication into a governed system process.

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, PPL Brain, AIBS Brain, and future Brains
  • 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 and decision recording

This protocol governs how Brains initiate, pass, receive, review, respond to, and escalate structured requests.

It 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

Those remain governed by the relevant Brain Canons, MWMS – System Architecture, MWMS – System Data Flow Map, MWMS – Brain Interaction Map, MWMS – Supabase Naming Standard, MWMS – PHP Build & Modularity Standard, Finance Brain, SIT Brain, and HeadOffice governance.

Definition / 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

The canonical communication chain is:

Brain Request
↓
Review / Routing
↓
Task / Workspace Visibility
↓
Decision / Response
↓
Status / Outcome
↓
HeadOffice Visibility
↓
Escalation if required

This aligns with MWMS system architecture, where work moves through structured requests, tasks, events, and outputs rather than informal tool-to-tool chatter.

Rule 1 – No Direct Brain-to-Brain Informal Messaging

No Brain may privately “talk” to 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

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

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 good rather than local Brain convenience

Cross-brain communication must never become a hidden subsystem beyond HeadOffice awareness.

This aligns with the MWMS governance model in which HeadOffice remains final authority over system direction and oversight.

Rule 4 – Request Lineage Preservation

Every Brain Request must preserve lineage.

If a request originates from an intake, opportunity, offer, task, or prior request, that linkage must remain visible.

Examples of lineage fields include:

  • intake_id
  • offer_id
  • parent_request_id
  • originating_task_id
  • source_origin

Lineage must not be lost during:

  • routing
  • list rendering
  • workspace opening
  • Brain handoff
  • decision recording
  • escalation

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

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

In default MWMS operation:

  • origin owner = requesting Brain
  • destination owner = receiving Brain
  • review owner = HeadOffice or designated Brain workspace logic
  • escalation owner = HeadOffice, SIT, Finance, or other authority depending on request type

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

A request without an outcome is incomplete.

Rule 8 – HeadOffice Opinion and Intervention Rule

Some requests will 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 with unclear ownership
  • requests that materially affect MWMS direction

The system must support HeadOffice intervention without breaking request lineage.

Rule 9 – Reusable Connector Pattern

This protocol establishes the standard precedent for all future Brain-to-Brain communication.

The first real implementation may begin with:

Research Brain → Affiliate Brain

But the pattern must be designed so it can later support:

  • Affiliate Brain → Ads Brain
  • Ads Brain → Experimentation Brain
  • Experimentation Brain → Finance Brain
  • Finance Brain → HeadOffice
  • any future Brain pair

The protocol must not be built as a one-off Research-only shortcut.

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 should display Brain Requests
  • WordPress should allow review, action, and visibility
  • Supabase should preserve request storage, lineage, and state history

This separation follows the existing MWMS architecture model.

Rule 11 – Naming Discipline Rule

All Supabase technical objects used to implement this protocol must follow the locked 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, and indexes.

Rule 12 – First Implementation Principle

The first implementation must be:

  • real
  • useful
  • narrow
  • traceable
  • extensible

It must not attempt to build the final universal communication system in one move.

The correct sequence is:

small implementation
↓
measured use
↓
observed weakness
↓
refinement
↓
standardisation across more Brains

This preserves MWMS discipline and prevents premature over-engineering.

Minimum Standard Brain Request Format

The standard Brain Request format must include the following fields at minimum:

  • request_id
  • origin_brain
  • destination_brain
  • request_type
  • request_title
  • request_summary
  • request_status
  • priority
  • intake_id
  • offer_id
  • parent_request_id
  • source_origin
  • routing_notes
  • response_summary
  • outcome_type
  • head_office_visible
  • escalation_flag
  • created_at
  • updated_at

Additional fields may be added in child implementations where needed, but these core fields establish the base contract.

Practical Interpretation

In practical MWMS use, this means:

Research Brain does not “message” Affiliate Brain.

Research Brain creates a Brain Request.

Affiliate Brain receives the Brain Request in a structured workspace.

The request remains visible to HeadOffice.

The status and outcome are recorded.

Any escalation remains inside the same governed chain.

That is the correct MWMS precedent.

Change Log

Version: v1.0
Date: 2026-03-27
Author: MWMS HeadOffice
Change: Initial creation of MWMS Brain-to-Brain Request Protocol. Established the formal structure for cross-brain communication, HeadOffice visibility, lineage preservation, request status model, outcome requirement, naming discipline alignment, and reusable connector precedent for all future Brain handoffs.

END – MWMS BRAIN-TO-BRAIN REQUEST PROTOCOL v1.0