Document Type: Specification
Status: Active
Authority: HeadOffice
Applies To: All cross Brain communication, routing, task handoff, signal visibility, result return logic, Brain site feedback, plugin/UI execution, and Supabase-connected coordination across MWMS
Parent: HeadOffice
Version: v1.3
Last Reviewed: 2026-05-11

Purpose

The MWMS Brain Connector Architecture defines how Brains communicate inside the MWMS ecosystem without relying on informal conversation, hidden assumptions, untracked handoffs, or uncontrolled updates.

Its role is to make cross Brain interaction:

structurally clear
operationally visible
lineage safe
status driven
governable
reviewable by HeadOffice
compatible with future plugin, UI, and Supabase execution systems

This page defines:

how Brains pass requests to one another
how MCR-approved content supports downstream Brain work
how signals move upward and downward through the system
how task schema logic supports routing and execution
how escalation is triggered and controlled
how outcomes are returned to the originating Brain
how Brain-site feedback is routed to HeadOffice
how HeadOffice maintains visibility across the full chain
how plugin/UI/Supabase systems execute without becoming Source of Truth layers

The goal is not conversational convenience.

The goal is governed system communication.

Scope

This specification applies to:

HeadOffice coordination across all MWMS Brains
Brain to Brain request creation and routing
Brain site to HeadOffice feedback routing
Supabase-backed task and request lineage
WordPress Brain-site workspace visibility
mwmsbrain.site operational coordination
mwmsheadofficebrain.site reporting and command visibility
plugin/UI execution surfaces
signal movement between operational, governance, and oversight layers
escalation paths involving HeadOffice, SIT, Finance, Compliance, Risk, and other authority systems
result handoff from execution layer back to originating system context
future connector expansion across new Brains, employees, automations, dashboards, and Brain Room systems

This page does not replace Brain Canons.

This page does not replace the MCR Source of Truth.

This page defines the connector architecture that sits between canonical Brain structure and operational execution.

Definition

The Brain Connector Architecture is the controlled transport and coordination layer of MWMS.

It governs how structured movement occurs between:

MCR
HeadOffice
Brain sites
Brain employees
plugin systems
UI systems
Supabase task systems
cross-Brain workflows
result and escalation pathways

It does not create canon.

It does not approve canon changes.

It does not allow Brain sites to update MCR directly.

It enables approved information, requests, signals, tasks, results, and feedback to move through the ecosystem in a governed way.

Core Principle

Brains do not communicate through informal narrative.

Brains communicate through structured connector logic.

Every cross Brain interaction must be:

declared
routed
stored
visible
lineage safe
status driven
outcome based
reviewable by HeadOffice

A Brain may originate a request.

A Brain may receive a request.

A Brain may process a request.

A Brain may return a result.

A Brain may generate feedback.

But the connector layer governs how that movement happens.

Source Of Truth Rule

The connector layer does not change the Source of Truth.

MCR remains the Source of Truth for:

canon
governance
architecture
standards
Brain structures
copy maps
routing rules
authority rules
build specifications

Brain sites remain operational environments.

Plugin/UI/Supabase systems remain execution environments.

The connector layer only transports structured objects between these layers.

It must not become a competing authority layer.

Approved Direction Of Authority

The approved authority direction is:

MCR → Brain Site → Plugin/UI/Supabase Execution

The approved learning and feedback direction is:

Brain Site → HeadOffice Review → MCR Decision

The prohibited direction is:

Brain Site → MCR Direct Update

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

Any proposed MCR change must go through HeadOffice review.

Architectural Position

The Brain Connector Architecture sits between:

HeadOffice Governance
↓
MCR Source Of Truth
↓
Brain Request Creation
↓
Routing And Review Logic
↓
Task And Execution Systems
↓
Plugin/UI/Supabase Execution
↓
Result Return And Status Closure
↓
HeadOffice Visibility And Escalation Control
↓
MCR Decision If Canon Change Is Required

It exists as the controlled transport layer of MWMS.

Connector Objective

The connector layer must ensure that:

no Brain handoff disappears into chat ambiguity
no task loses context when passed between systems
no result returns without traceable origin
no escalation occurs outside a governed chain
no Brain exceeds its authority because routing was unclear
no plugin/UI system becomes an unapproved decision authority
no Supabase process silently creates canon logic
no system health view depends on manual memory alone
no Brain-site feedback directly alters MCR

Connector discipline is what allows MWMS to scale beyond manual conversation.

Connector Layers

Layer 1 — Origin Layer

This is where a request, signal, or trigger begins.

Possible origins include:

HeadOffice directive
MCR-approved workflow
Research insight
Affiliate opportunity evaluation
Ads performance anomaly
Experimentation requirement
Finance risk trigger
SIT integrity event
Compliance alert
Risk signal
manual human instruction
automated system trigger
Brain Room message
newsletter intelligence signal
plugin/UI event

The origin layer must create a declared starting point.

Nothing should move invisibly.

Layer 2 — Request Layer

The origin becomes a structured Brain Request.

This request captures:

source Brain
destination Brain
request type
purpose
priority
lineage fields
routing status
review ownership
escalation conditions
expected outcome
source context
required evidence
related MCR source page if relevant

This is the formal handoff object.

A request is not just a message.

A request is the governed object that controls the work chain.

Layer 3 — Routing Layer

The routing layer determines:

which Brain owns the next action
whether the request is valid inside that Brain’s authority
whether the request needs review before activation
whether supporting Brains must be declared
whether escalation controls must be attached at creation
whether HeadOffice visibility is required immediately
whether the request touches MCR authority

This is the control point that prevents Brain drift.

Layer 4 — Task Execution Layer

Once routed, the request may create one or more executable tasks.

Examples include:

research task
offer review task
experiment design task
financial check task
compliance review task
risk review task
enforcement review task
dashboard update task
implementation task
content production task
data validation task
plugin/UI build task

The request remains the parent object.

Tasks are execution children.

Tasks never replace requests.

Layer 5 — Plugin/UI/Supabase Execution Layer

This layer handles the operational execution surface.

It may include:

WordPress plugin screens
Brain Room interfaces
dashboard panels
intake forms
task queues
Supabase task records
Supabase event logs
status fields
employee execution panels
operational reporting views

This layer may execute approved workflows.

It must not define new canon.

It must not create unapproved rules.

It must not directly update MCR.

Layer 6 — Result Layer

Execution outputs return to the request chain as structured results.

Examples include:

recommendation
verdict
experiment definition
routed escalation
blocked decision
approved progression
rejected progression
system warning
evidence package
risk classification
compliance classification
learning summary
required next step

Results must attach to the original request lineage.

“Done” is not a valid governed result.

A valid result must state:

what was decided
why it was decided
what evidence supports it
what happens next
who owns the next step
whether HeadOffice review is required

Layer 7 — Visibility Governance Layer

HeadOffice must be able to see:

request creation
routing state
current owner
source Brain
destination Brain
supporting Brains
escalation flags
linked tasks
result status
final outcome
unresolved blockers
feedback requiring review
suggested MCR changes
closed decisions

This ensures system-wide observability.

HeadOffice visibility is not optional for critical cross-Brain work.

Layer 8 — Feedback And Review Layer

Brain sites may generate operational feedback.

This feedback may include:

unclear instructions
missing fields
repeated workflow friction
plugin/UI confusion
task routing failure
dashboard gaps
evidence gaps
conflict between Brain logic
suggested new field
suggested page update
suggested canon update

This feedback must route to HeadOffice.

HeadOffice decides whether the feedback becomes:

MCR update
copy map update
plugin/UI update
Supabase schema update
task schema update
dashboard update
parked insight
rejected suggestion
future build item

The connector layer must support feedback without allowing uncontrolled canon changes.

Task Schema Logic

The connector layer follows this parent-child structure:

Object	Role
Brain Request	Parent object
Signal	Trigger input
Task	Execution object
Result	Return object
Escalation	Governed branch of same lineage
Feedback	Operational learning object
HeadOffice Review	Approval or rejection layer
MCR Decision	Canon/source-of-truth change decision

Requests govern tasks.

Tasks never replace requests.

Signals trigger requests.

Results close or continue requests.

Feedback routes to HeadOffice.

HeadOffice decides whether MCR changes.

Minimum Connector Fields

Every governed connector object should support the following minimum fields where relevant:

request_id
request_type
origin_brain
destination_brain
primary_brain
supporting_brains
source_origin
source_page
source_system
priority
status
outcome_type
created_at
updated_at
review_owner
escalation_owner
related_task_ids
parent_request_id
result_summary
closure_reason
feedback_required
head_office_review_required
mcr_update_suggested
mcr_update_status

Standard Request Status Flow

The standard request status flow is:

new
under_review
routed
in_progress
responded
escalated
blocked
closed

Additional optional statuses may include:

parked
rejected
awaiting_evidence
awaiting_head_office_review
awaiting_mcr_decision
returned_for_revision

Statuses must support visibility.

Statuses must not hide uncertainty.

Signal Flow

Signals trigger requests.

Signals do not replace requests.

Signal sources may include:

experiment results
financial thresholds
performance anomalies
evidence changes
compliance alerts
progression attempts
research signals
newsletter intelligence
customer behaviour shifts
data quality issues
plugin errors
task failures
Brain Room instructions

A signal becomes operational only when it is converted into a governed request or task.

Escalation Flow

Escalation transfers authority when:

risk exceeds thresholds
evidence is insufficient
conflict is unresolved
integrity is compromised
compliance risk is detected
capital exposure increases
canon authority may be affected
task execution fails repeatedly
downstream systems disagree
HeadOffice visibility is required

Escalation remains inside original lineage.

Escalation must not create a disconnected side conversation.

Result Handoff

Results must:

map to the originating request
state outcome clearly
define next step
identify decision owner
state confidence level where relevant
state evidence basis
remain visible to HeadOffice
attach to the request lineage

A governed result must answer:

What was requested?
What was found or done?
What decision or recommendation was produced?
What evidence supports the result?
What happens next?
Does HeadOffice need to review anything?
Does MCR need a proposed update?

Standard Connector Flow Patterns

Pattern 1 — Research → Affiliate

Research Brain identifies opportunity signal
↓
Brain Request created
↓
Affiliate Brain evaluates opportunity
↓
Velocity Decision Engine produces decision
↓
result returned to originating research context
↓
HeadOffice visibility maintained

Pattern 2 — Affiliate → Experimentation

Affiliate Brain approves test candidate
↓
Brain Request created
↓
Experimentation Brain defines test structure
↓
Phase 4 testing protocol engaged
↓
test result returned to Affiliate Brain
↓
Signal Confidence Structure interprets result
↓
HeadOffice visibility maintained

Pattern 3 — Experimentation → Finance

Signal confidence threshold reached
↓
Brain Request created
↓
Finance Brain evaluates capital exposure
↓
risk classification returned
↓
HeadOffice visibility updated

Pattern 4 — Ads → Research Feedback Loop

Ads Brain observes signal anomaly
↓
Brain Request created
↓
Research Brain investigates behavioural explanation
↓
insight returned to Ads Brain
↓
HeadOffice visibility maintained if impact is material

Pattern 5 — SIT Escalation Flow

SIT detects structural breach
↓
Escalation request created
↓
HeadOffice review triggered
↓
decision returned through same lineage
↓
MCR update considered only if HeadOffice approves

Pattern 6 — Brain Site → HeadOffice Feedback → MCR Decision

Brain site identifies operational friction or improvement
↓
Feedback object created
↓
HeadOffice reviews feedback
↓
HeadOffice classifies as approve, reject, park, or investigate
↓
MCR update occurs only if approved
↓
Brain site receives updated operational copy if needed

Pattern 7 — MCR → Brain Site → Plugin/UI Execution

MCR page classified as Copy To Brain or Later Plugin/UI
↓
HeadOffice approves operational destination
↓
Brain site receives working version or build specification
↓
Plugin/UI/Supabase executes approved workflow
↓
results and feedback return through connector layer
↓
HeadOffice visibility maintained

Connector Governance Rules

The following rules govern the connector layer:

Routing before execution.
Primary Brain must be declared.
Supporting Brains must be declared where relevant.
Lineage must be preserved.
Tasks are subordinate to requests.
Signals trigger requests.
Escalation remains inside lineage.
Results must return.
HeadOffice visibility is required.
Connector logic must remain expandable.
Informal communication is not canonical precedent.
Brain sites may generate feedback but cannot update MCR directly.
Plugin/UI systems may execute workflows but cannot define canon.
Supabase may store and support execution but cannot become Source of Truth.
MCR changes require HeadOffice review and approval.

Connector Authority Boundaries

Layer	May Do	Must Not Do
MCR	Define canon, standards, architecture, copy maps	Operate as daily workflow UI
Brain Site	Execute approved operating workflows	Rewrite MCR canon
Plugin/UI	Display, collect, route, execute	Become hidden authority
Supabase	Store tasks, events, results, lineage	Create unapproved rules
Brain Employee	Process assigned tasks	Exceed Brain authority
HeadOffice	Review, approve, escalate, update MCR	Ignore lineage or evidence

Relationship To MCR To Brain Copy Rule

The MWMS MCR To Brain Copy Rule defines whether a page should remain MCR-only, be copied to a Brain site, or become a later plugin/UI surface.

The MWMS Brain Connector Architecture defines how approved information, requests, signals, tasks, results, escalations, and feedback move after classification.

Together they enforce:

MCR decides what may move. Connector Architecture controls how it moves.

Relationship To MCR Brain Wiring Map

The MWMS MCR Brain Wiring Map defines the structural relationship between MCR, Brain sites, plugin/UI systems, Supabase, and HeadOffice review.

The MWMS Brain Connector Architecture defines the operating movement between those layers.

Together they enforce:

The Wiring Map defines the system shape. The Connector Architecture defines the movement inside that shape.

Governance Role

This specification ensures:

cross-Brain communication is structured
task handoffs are visible
source-of-truth authority remains protected
Brain-site feedback is captured safely
HeadOffice can review system movement
plugin/UI systems do not become ungoverned authority layers
Supabase task and event records remain tied to approved lineage
scaling does not depend on memory or informal chat

Drift Protection

This architecture protects against:

informal Brain handoffs
lost task context
disconnected results
untracked escalations
unclear Brain ownership
hidden plugin authority
Supabase becoming de facto canon
Brain sites directly changing MCR
feedback bypassing HeadOffice
decision lineage disappearing
dashboards showing actions without source context

All connector movement must remain visible, structured, and reviewable.

Architectural Intent

Connector Architecture transforms MWMS from:

conversation-based coordination

into:

governed system communication

It enables:

traceable requests
visible signal movement
stable escalation control
reliable decision lineage
dashboard readiness
automation readiness
Brain Room readiness
plugin/UI readiness
HeadOffice oversight
controlled MCR improvement

Connector discipline enables scalable MWMS intelligence.

Change Log

v1.1 — 2026-03-31

Title updated to remove dash character in accordance with MWMS Page Naming Standard.

v1.2 — 2026-04-21

Added Standard Connector Flow Patterns section to improve operational clarity and implementation readiness.

v1.3 — 2026-05-11

Expanded specification to align with updated MCR To Brain Copy Rule and MCR Brain Wiring Map.

Added:

Source Of Truth Rule
approved authority direction
Brain Site feedback path
Brain to MCR direct-update ban
plugin/UI/Supabase execution layer
feedback and review layer
expanded task schema logic
new connector flow patterns for Brain Site feedback and MCR to Brain execution
connector authority boundaries
relationship to MCR To Brain Copy Rule
relationship to MCR Brain Wiring Map
stronger drift protection for Brain sites, plugin/UI systems, and Supabase execution

Change Impact Declaration

Pages Created:
None

Pages Updated:
MWMS Brain Connector Architecture

Pages Deprecated:
None

Registries Requiring Update:
None

Canon Version Update Required:
No

Change Log Entry Required:
Optional — only required if HeadOffice wants this connector expansion recorded in the current MWMS System Change Log.