MWMS MCR

MWMS Standard Cross Brain Flow

Document Type: Standard
Status: Active
Version: v1.1
Authority: HeadOffice
Parent: MWMS Brain Connector Architecture
Applies To: All Brains, Brain Sites, HeadOffice, Supabase Request Records, Plugin/UI Execution Systems, Brain Room, and Future AI Employee Routing
Last Reviewed: 2026-05-11

Purpose

The MWMS Standard Cross Brain Flow defines the canonical structure used when one Brain sends a structured request, signal, decision dependency, or feedback item to another Brain.

It ensures all cross-Brain movement:

  • remains traceable
  • maintains authority clarity
  • preserves decision lineage
  • supports consistent routing logic
  • enables future Supabase implementation
  • enables Brain Room task automation
  • supports plugin/UI execution
  • protects MCR as the Source of Truth
  • maintains HeadOffice visibility
  • prevents Brain-to-Brain communication drift

Without a standard flow structure, cross-Brain communication becomes inconsistent, difficult to track, difficult to govern, and difficult to automate.

This page defines the minimum structure required for stable cross-Brain coordination.

This page also clarifies that cross-Brain flow can generate operational feedback, but it cannot directly update MCR canon.

MCR changes require HeadOffice review and approval.

Source page provided for update:

Scope

This standard applies to:

  • Brain-to-Brain requests
  • cross-Brain signal routing
  • cross-Brain decision dependencies
  • multi-Brain evaluation flows
  • HeadOffice visibility interpretation
  • future AI employee task routing
  • Supabase routing structures
  • Brain Room structured tasks
  • Brain-site operational feedback
  • plugin/UI triggered Brain requests
  • dashboard-driven escalations
  • structured result return
  • HeadOffice review paths

This standard does not define:

  • how each Brain internally performs analysis
  • how each Brain internally stores intelligence
  • how dashboards render signals
  • statistical methods
  • capital allocation rules
  • final canon editing authority
  • plugin build implementation details
  • Supabase schema implementation details

Those remain governed by each Brain’s Canon, Framework structure, MCR standards, Supabase schema standards, and HeadOffice governance.

Core Principle

Every cross-Brain interaction must:

  • identify origin
  • identify destination
  • define signal meaning
  • define decision requirement
  • define confidence posture
  • define escalation conditions
  • define lineage
  • preserve result return
  • maintain HeadOffice visibility where required
  • protect MCR authority

Cross-Brain flows must remain interpretable by:

  • humans
  • AI employees
  • HeadOffice governance layer
  • future automation layers
  • plugin/UI systems
  • Supabase task and request systems

The approved movement model is:

Brain Request → Routing → Task Execution → Result Return → HeadOffice Visibility → Escalation Or Closure

If a result suggests a system improvement, the approved feedback model is:

Brain Feedback → HeadOffice Review → MCR Decision

The prohibited model is:

Brain Feedback → Direct MCR Update

Source Of Truth Rule

Cross-Brain flows do not create canon.

Cross-Brain flows may produce:

  • signals
  • recommendations
  • findings
  • warnings
  • confidence assessments
  • results
  • escalations
  • operational feedback
  • suggested improvements

But these outputs do not directly become MCR authority.

MCR remains the Source of Truth for:

  • canon pages
  • governance rules
  • architecture definitions
  • standards
  • Brain structures
  • copy maps
  • authority rules
  • system rules

Any proposed change to MCR must pass through:

HeadOffice Review → MCR Decision

Standard Cross Brain Request Structure

Each cross-Brain request must contain the following fields.

1. Request Origin Brain

Identifies where the signal, request, or trigger originates.

Examples:

  • Research Brain
  • Affiliate Brain
  • Ads Brain
  • Experimentation Brain
  • Finance Brain
  • Customer Brain
  • Data Brain
  • Content Brain
  • Risk Brain
  • Compliance Brain
  • HeadOffice Brain
  • Brain Room
  • Plugin/UI system

The origin must be explicit.

No request should enter the system without a declared origin.

2. Destination Brain

Identifies which Brain is responsible for the next interpretation, action, validation, or decision step.

Destination must be a valid Brain defined in the MWMS Architecture Registry or approved HeadOffice structure.

Examples:

  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • HeadOffice
  • Compliance Brain
  • Risk Brain
  • Data Brain
  • Ads Brain
  • Content Brain

The destination Brain must have authority to handle the request.

If authority is unclear, the request must route to HeadOffice for review.

3. Request Type

Defines the structural nature of the request.

Examples:

  • opportunity evaluation
  • experiment validation
  • capital readiness evaluation
  • signal clarification
  • decision support request
  • risk review request
  • compliance review request
  • signal enrichment request
  • routing clarification request
  • HeadOffice review request
  • MCR update suggestion
  • dashboard update request
  • plugin/UI build request
  • Brain Room request

Request type must be stable and descriptive.

4. Signal Type

Defines the classification of signal being transmitted.

Examples:

  • opportunity signal
  • behavioural signal
  • performance signal
  • statistical signal
  • confidence signal
  • financial exposure signal
  • risk signal
  • compliance signal
  • dependency signal
  • alignment signal
  • market signal
  • customer signal
  • execution signal
  • system friction signal

Signal type helps the receiving Brain interpret the request correctly.

5. Signal Confidence Level

Defines how reliable the originating Brain considers the signal.

Examples:

  • low confidence
  • emerging signal
  • moderate confidence
  • strong signal
  • validated signal

Confidence definitions remain governed by:

  • Experimentation Brain
  • Data Brain
  • Research Brain
  • HeadOffice statistical and decision standards

Low confidence signals may still be useful, but they must not be treated as validated evidence.

6. Decision Requirement

Defines what type of decision is expected from the destination Brain.

Examples:

  • evaluate viability
  • validate test structure
  • confirm statistical sufficiency
  • confirm capital exposure tolerance
  • approve progression
  • reject progression
  • request additional signal
  • route to alternative Brain
  • classify risk
  • classify compliance exposure
  • confirm tracking readiness
  • confirm operational readiness
  • recommend HeadOffice review

The decision requirement must be visible before work begins.

7. Dependency Requirements

Identifies prerequisite conditions required before decision progression can occur.

Examples:

  • sufficient signal density
  • defined hypothesis structure
  • measurement integrity confirmation
  • tracking readiness confirmation
  • capital availability confirmation
  • compliance review completion
  • risk review completion
  • offer data completeness
  • research evidence sufficiency
  • landing page readiness
  • creative readiness
  • dashboard visibility readiness

Dependencies must be explicitly visible.

Hidden dependencies create structural instability.

8. Escalation Conditions

Defines when the request must be escalated beyond the destination Brain.

Examples:

  • signal conflict detected
  • insufficient confidence
  • capital exposure risk
  • compliance risk detected
  • risk threshold exceeded
  • dependency unresolved
  • structural ambiguity detected
  • governance interpretation required
  • Brain authority conflict
  • repeated task failure
  • plugin/UI execution failure
  • MCR update suggested

Escalations typically route to:

  • HeadOffice
  • Finance Brain
  • SIT Brain
  • Compliance Brain
  • Risk Brain
  • Data Brain

Escalation must remain inside the original lineage.

9. Capital Sensitivity Flag

Indicates whether the decision may influence capital exposure.

Values:

  • yes
  • no
  • unknown

If yes, Finance Brain visibility may be required.

If capital exposure is material, Finance Brain review is required before progression.

10. Experiment Requirement Flag

Indicates whether structured testing is required before progression.

Values:

  • experiment required
  • experiment optional
  • experiment not required
  • unknown

Experimentation Brain maintains authority over test validation.

If experiment requirement is unclear, the request should route to Experimentation Brain or HeadOffice for interpretation.

11. Lineage Reference

Defines where the request sits in the broader decision pathway.

Examples:

  • Research → Affiliate
  • Affiliate → Research
  • Affiliate → Experimentation
  • Experimentation → Finance
  • Finance → HeadOffice
  • Ads → Research
  • Data → Experimentation
  • Brain Site → HeadOffice
  • Brain Room → Brain Request
  • Plugin/UI → Brain Request

Lineage enables:

  • decision traceability
  • signal interpretation context
  • dashboard clarity
  • historical learning continuity
  • future automation reliability
  • auditability

Lineage must never be lost.

12. Result Return Requirement

Every cross-Brain request must define how the result returns.

A valid result must include:

  • result summary
  • outcome type
  • decision made
  • evidence basis
  • confidence posture
  • next step
  • owner of next step
  • escalation requirement if any
  • HeadOffice visibility requirement if any
  • MCR update suggestion if any

“Done” is not a valid governed result.

The receiving Brain must return a meaningful outcome to the originating context.

13. HeadOffice Visibility Requirement

Each cross-Brain flow must state whether HeadOffice visibility is required.

HeadOffice visibility is required when the request affects:

  • strategy
  • capital
  • compliance
  • risk
  • MCR authority
  • Brain authority conflict
  • system architecture
  • plugin/UI build priority
  • major opportunity progression
  • test progression
  • scaling decision
  • system-wide reporting

HeadOffice does not need to manually intervene in every flow, but the system must allow HeadOffice to see and review important movement.

14. MCR Update Suggestion Flag

Each cross-Brain flow may include a field indicating whether the request result suggests an MCR update.

Values:

  • yes
  • no
  • unknown

If yes, the result must route to HeadOffice.

The Brain or Brain site may suggest a change.

It may not perform the change directly.

Canonical Reference Flow

The baseline MWMS cross-Brain operating flow is:

Research Brain
identifies opportunity signal
↓
Affiliate Brain
evaluates commercial viability
↓
Experimentation Brain
validates test structure
↓
Finance Brain
evaluates capital exposure tolerance
↓
HeadOffice
observes system posture and approves governance-level decisions where required

Flow Characteristics

The standard flow demonstrates:

  • multi-layer governance
  • signal validation progression
  • capital discipline integration
  • statistical discipline integration
  • decision traceability
  • HeadOffice visibility
  • authority separation
  • structured result return
  • safe escalation

This flow acts as the reference pattern for future flows.

Practical Standard Flow Patterns

Pattern 1 — Research Brain To Affiliate Brain

Research Brain identifies an opportunity signal.

A structured request is created.

Affiliate Brain evaluates:

  • commercial viability
  • offer strength
  • funnel potential
  • margin logic
  • audience fit
  • channel suitability
  • test readiness

Affiliate Brain returns:

  • verdict
  • recommendation
  • next step
  • confidence level
  • evidence summary

HeadOffice visibility is maintained where the opportunity is material.

Pattern 2 — Affiliate Brain To Experimentation Brain

Affiliate Brain approves a test candidate.

A structured request is created.

Experimentation Brain evaluates:

  • hypothesis quality
  • test structure
  • minimum viable test
  • sample and signal expectations
  • success criteria
  • failure criteria
  • measurement readiness

Experimentation Brain returns:

  • test structure
  • test decision
  • required metrics
  • confidence posture
  • next step

Pattern 3 — Experimentation Brain To Finance Brain

Experimentation Brain identifies that a test has produced enough signal to consider further spend.

A structured request is created.

Finance Brain evaluates:

  • capital exposure
  • risk tolerance
  • cashflow impact
  • downside exposure
  • controlled loss limits
  • scaling readiness
  • survivability impact

Finance Brain returns:

  • approval
  • rejection
  • budget limit
  • pacing condition
  • risk classification
  • escalation if required

Pattern 4 — Finance Brain To HeadOffice

Finance Brain identifies a capital, risk, or survivability issue that affects the broader MWMS system.

A structured request is created.

HeadOffice reviews:

  • system posture
  • capital exposure
  • opportunity priority
  • strategic alignment
  • risk concentration
  • cross-Brain implications

HeadOffice returns:

  • approve
  • reject
  • pause
  • park
  • investigate
  • route to another Brain
  • update operating instruction
  • consider MCR update

Pattern 5 — Ads Brain To Research Brain

Ads Brain observes a performance anomaly.

A structured request is created.

Research Brain investigates:

  • audience behaviour
  • market signal
  • message mismatch
  • offer perception
  • competitor pressure
  • search or demand change
  • customer motivation shift

Research Brain returns:

  • explanation
  • signal classification
  • recommended next step
  • evidence strength
  • confidence level

Pattern 6 — Brain Site Feedback To HeadOffice

A Brain site identifies that an operational workflow, page, field, dashboard, or plugin/UI screen is unclear or incomplete.

A structured feedback request is created.

HeadOffice reviews:

  • whether the issue is local or system-wide
  • whether an MCR page needs updating
  • whether a Brain working copy needs updating
  • whether a plugin/UI specification needs updating
  • whether a Supabase schema field is needed
  • whether the issue should be parked or rejected

HeadOffice returns:

  • approve
  • reject
  • park
  • investigate
  • route to another Brain
  • update working copy
  • approve MCR update
  • update plugin/UI specification

Brain site does not directly update MCR.

Pattern 7 — Brain Room To Cross Brain Request

A Brain Room message may trigger a structured cross-Brain request.

Brain Room captures:

  • instruction
  • source context
  • requested Brain
  • urgency
  • expected output
  • related task or page

The connector layer converts this into a standard request.

The request then follows normal routing, execution, result return, and closure logic.

Brain Room is an operational input surface.

It is not a replacement for the cross-Brain flow standard.

Pattern 8 — MCR To Brain Site Operational Flow

MCR defines or updates a page.

HeadOffice classifies the page as:

  • MCR Only
  • Copy To Brain
  • Later Plugin Or UI

If Copy To Brain:

  • the page is transformed into an operational working version
  • the Brain site uses it for daily workflow
  • feedback returns to HeadOffice if needed

If Later Plugin Or UI:

  • the page becomes a build specification
  • plugin/UI/Supabase execution is built later
  • results and feedback remain connected to HeadOffice visibility

MCR remains Source of Truth.

Governance Interpretation

HeadOffice observes cross-Brain movement.

HeadOffice does not override Brain authority unless governance conditions require escalation.

Cross-Brain flows must maintain:

  • clear authority boundaries
  • clear decision ownership
  • clear lineage visibility
  • clear escalation paths
  • clear result return
  • clear MCR protection

HeadOffice intervenes when the request affects:

  • system direction
  • capital exposure
  • compliance risk
  • structural risk
  • canon authority
  • unresolved Brain conflict
  • major operating priority

Relationship To Connector Architecture

This standard supports:

  • MWMS Brain Connector Architecture
  • MWMS Brain To Brain Request Protocol
  • MWMS MCR Brain Wiring Map
  • MWMS MCR To Brain Copy Rule
  • MWMS Decision Flow Map Combined View
  • HeadOffice Active Command Dashboard
  • HeadOffice Cross Brain Status Board
  • Cross Brain Signal Confidence Structure
  • Brain Room task routing
  • Supabase request implementation
  • future AI employee orchestration

The Connector Architecture defines the transport layer.

This standard defines the flow structure used inside that transport layer.

Relationship To MCR To Brain Copy Rule

The MCR To Brain Copy Rule defines whether MCR content should remain MCR-only, copy to Brain, or become plugin/UI later.

This Cross Brain Flow standard defines what happens when that operational content starts moving between Brains.

Together they enforce:

MCR controls what knowledge moves. Cross Brain Flow controls how Brain work moves.

Relationship To Brain To Brain Request Protocol

The Brain To Brain Request Protocol defines how Brains formally create, receive, route, respond to, and close requests.

This Cross Brain Flow standard defines the minimum structure and canonical flow patterns that those requests should follow.

Together they enforce:

Requests are the objects. Flows are the pathways.

Future Implementation

This structure is designed for later implementation inside:

  • Supabase request tables
  • Supabase task tables
  • Supabase event logs
  • Brain Room task routing
  • AI employee orchestration
  • dashboard lineage panels
  • automation triggers
  • WordPress Brain-site workspaces
  • plugin/UI request surfaces
  • HeadOffice command dashboards

Each field defined here maps directly to future structured request objects.

Structural Integrity Rule

Cross-Brain flows must remain:

  • interpretable
  • traceable
  • auditable
  • non-ambiguous
  • structurally consistent
  • lineage safe
  • HeadOffice visible where required
  • protected from MCR drift

Any new routing structure must align with this standard.

If a flow cannot be clearly traced from origin to result, it is not structurally ready.

Drift Protection

This standard protects against:

  • informal Brain handoffs
  • hidden task routing
  • untracked decision dependencies
  • lost lineage
  • dashboards without source context
  • Supabase records without request context
  • plugin/UI actions bypassing Brain requests
  • Brain Room messages becoming unstructured work
  • Brain feedback becoming unapproved canon
  • Brain sites directly updating MCR
  • capital progression without Finance visibility
  • test progression without Experimentation visibility
  • system changes without HeadOffice review

Architectural Intent

The architectural intent is to turn MWMS cross-Brain movement from:

conversation-based handoff

into:

structured, traceable, governed system flow

This ensures MWMS can scale across:

  • multiple Brains
  • multiple operators
  • future AI employees
  • plugin systems
  • dashboards
  • Supabase task systems
  • Brain Room workflows
  • HeadOffice oversight

The flow must remain practical enough for daily work and disciplined enough for long-term system integrity.

Final Rule

Every cross-Brain flow must have:

  • origin
  • destination
  • request type
  • signal type
  • confidence posture
  • decision requirement
  • dependency requirements
  • escalation conditions
  • lineage reference
  • result return
  • HeadOffice visibility where required
  • MCR update suggestion flag where relevant

No cross-Brain flow may directly update MCR canon.

All proposed MCR changes must pass through:

HeadOffice Review → MCR Decision

Change Log

v1.0 — 2026-04-21

Initial creation of MWMS Standard Cross Brain Flow defining canonical request structure for stable cross-Brain routing, decision lineage clarity, and future automation readiness.

Established baseline structure supporting Connector Architecture, Decision Flow Map, and HeadOffice visibility layer.

v1.1 — 2026-05-11

Expanded standard to align with:

  • MWMS MCR To Brain Copy Rule
  • MWMS MCR Brain Wiring Map
  • MWMS Brain Connector Architecture
  • MWMS Brain To Brain Request Protocol

Added:

  • Source Of Truth Rule
  • MCR update suggestion flag
  • result return requirement
  • HeadOffice visibility requirement
  • Brain Site Feedback To HeadOffice pattern
  • Brain Room To Cross Brain Request pattern
  • MCR To Brain Site Operational Flow pattern
  • relationship to MCR To Brain Copy Rule
  • relationship to Brain To Brain Request Protocol
  • stronger drift protection for plugin/UI, Supabase, Brain Room, and MCR authority

Change Impact Declaration

Pages Updated:
MWMS Standard Cross Brain Flow

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 flow expansion recorded in the current MWMS System Change Log.