Document Type: Specification
Status: Active
Authority: HeadOffice
Applies To: All cross Brain communication, routing, task handoff, signal visibility, and result return logic across MWMS
Parent: HeadOffice
Version: v1.1
Last Reviewed: 2026-03-31
Purpose
MWMS Brain Connector Architecture exists to define how Brains communicate inside the MWMS ecosystem without relying on informal conversation, hidden assumptions, or untracked handoffs.
Its role is to make cross Brain interaction structurally clear, operationally visible, and governable as the ecosystem expands.
This page exists to define:
• how Brains pass requests to one another
• how signal flow moves 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 HeadOffice maintains visibility across the full chain
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
• Supabase backed task and request lineage
• WordPress workspace visibility where relevant
• signal movement between operational, governance, and oversight layers
• escalation paths involving HeadOffice, SIT, Finance, and other authority systems
• result handoff from execution layer back to originating system context
• future connector expansion across new Brains, employees, and automation layers
This page does not replace Brain Canons.
This page defines the connector architecture that sits between them.
Definition
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.
But the connector layer governs how that movement happens.
Architectural Position
The Brain Connector Architecture sits between:
HeadOffice governance
↓
Brain request creation
↓
routing and review logic
↓
task and execution systems
↓
result return and status closure
↓
HeadOffice visibility and escalation control
It exists as the controlled transport layer of MWMS.
Connector Objective
The connector layer must ensure that:
• no Brain handoff disappears into chat like 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 system health view depends on manual memory alone
Architecture Overview
1. Connector Layers
The MWMS connector model contains six layers:
Layer 1 Origin Layer
This is where a request, signal, or trigger begins.
Possible origins include:
• HeadOffice directive
• Research insight
• Affiliate opportunity evaluation
• Ads performance anomaly
• Experimentation requirement
• Finance risk trigger
• SIT integrity event
• manual human instruction
• automated system trigger
The origin layer must create a declared starting point.
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
This is the formal handoff object.
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
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:
• research task
• offer review task
• experiment design task
• financial check task
• enforcement review task
• dashboard update task
• implementation task
The request remains the parent object.
Tasks are execution children.
Layer 5 Result Layer
Execution outputs return to the request chain as structured results.
Examples:
• recommendation
• verdict
• experiment definition
• routed escalation
• blocked decision
• approved progression
• rejected progression
• system warning
• evidence package
Results must attach to the original request lineage.
Layer 6 Visibility Governance Layer
HeadOffice must be able to see:
• request creation
• routing state
• current owner
• escalation flags
• linked tasks
• result status
• final outcome
• unresolved blockers
This ensures system wide observability.
Task Schema Logic
Core Relationship Model
The connector architecture uses a parent child logic:
Brain Request = governing parent object
Task = executable child object
Result = return object linked to request and task lineage
Signal = event, metric, or status input that may trigger request creation
Escalation = governed branch of the same lineage, not a separate disconnected process
This means:
• a request may create zero, one, or many tasks
• a task must always belong to a request or a controlled system trigger
• a result must map back to the originating request
• an escalation must preserve the same request lineage
• closure must happen at request level, not only task level
Minimum Connector Fields
Every Brain Request should support at minimum:
• request_id
• request_type
• origin_brain
• destination_brain
• primary_brain
• supporting_brains
• source_origin
• priority
• status
• outcome_type
• created_at
• updated_at
• created_by
• review_owner
• escalation_owner
• intake_id where relevant
• offer_id where relevant
• experiment_id where relevant
• related_task_ids
• parent_request_id where relevant
• result_summary
• escalation_reason where relevant
• closure_reason where relevant
Execution Task Fields
Every execution task should support at minimum:
• task_id
• parent_request_id
• task_type
• assigned_brain
• assigned_employee_or_system
• task_status
• execution_notes
• evidence_links where relevant
• started_at
• completed_at
• result_id where relevant
• escalation_flag
Schema Logic Rule
Request lineage must always be stronger than task convenience.
If a task is easy to create but breaks request traceability, the architecture is wrong.
Request Flow
Standard Request Flow
Origin Signal or Instruction
↓
Brain Request Created
↓
Review Routing
↓
Destination Brain Accepted
↓
Task Creation if required
↓
Work Performed
↓
Result Returned
↓
Outcome Recorded
↓
Request Closed or Escalated
↓
HeadOffice Visibility Maintained Throughout
Request Flow Rules
• every cross Brain action begins with a Brain Request
• every request must declare origin and destination
• every request must have a visible status
• every request must end in an outcome state
• requests must not vanish after work is performed
• routing must occur before execution guidance
• multi Brain work must declare one primary Brain
Standard Request Status Flow
Minimum statuses:
• new
• under_review
• routed
• in_progress
• responded
• escalated
• blocked
• closed
Brains may use narrower internal stages, but must not break the core connector status model.
Signal Flow
Purpose of Signal Flow
Signal flow defines how MWMS detects what needs action.
Signals are not the same as requests.
Signals are inputs.
Requests are structured responses to those inputs.
Signal Sources
Signals may originate from:
• dashboard KPI movement
• experiment outcomes
• financial thresholds
• anomaly detection
• evidence updates
• compliance violations
• stage progression attempts
• manual executive review
• research density shifts
• campaign deterioration
• task failure clusters
• unresolved blockers
Signal Direction Types
Upward Signal Flow
Operational Brains send meaningful signals upward to HeadOffice.
Examples:
• Ads Brain flags performance instability
• Experimentation Brain flags invalid test conditions
• Finance Brain flags capital exposure
• SIT flags structural integrity failure
Downward Signal Flow
HeadOffice or authority Brains send controlled signals downward.
Examples:
• freeze progression
• request re review
• enforce escalation
• block launch
• require evidence
• require financial signoff
Lateral Signal Flow
One Brain may generate a signal relevant to another Brain, but the transfer must still go through connector logic.
Example:
Research Brain detects emerging demand signal
→ connector creates structured request
→ Affiliate Brain evaluates opportunity
Lateral still means governed.
Signal Rule
Signals may trigger requests.
Signals do not replace requests.
Escalation Flow
Purpose
Escalation exists to preserve governance when normal Brain autonomy is insufficient.
Escalation is not failure.
It is controlled authority transfer.
Escalation Triggers
Escalation should be triggered when:
• request crosses Brain authority boundaries
• financial risk exceeds allowed thresholds
• governance breach detected
• data integrity compromised
• unresolved blocker prevents closure
• conflicting Brain conclusions require arbitration
• stage progression attempted without required evidence
• system health indicators show instability
• compliance exposure detected
• HeadOffice review explicitly required
Standard Escalation Chain
Request issue
↓
Escalation Flag Raised
↓
Escalation Owner Assigned
↓
Review Authority Activated
↓
Decision Returned
↓
Outcome Attached to Same Lineage
↓
Request Continues, Closes, or Blocks
Escalation Owners
Depending on issue type:
• HeadOffice
• SIT Brain
• Finance Brain
• governed Brain authority
• human executive layer
Escalation Rules
• escalation remains attached to original lineage
• escalation must not create disconnected side process
• escalation reason must be visible
• escalation owner must be explicit
• escalation outcome must be recorded
• escalated requests must not return to silent state
Result Handoff
Purpose
Result handoff defines how completed work returns to the originating context.
Work is not complete when a task ends.
Work is complete when the result is returned, interpreted, and recorded correctly.
Standard Result Handoff Flow
Task Completion
↓
Result Object Created
↓
Result Returned to Parent Request
↓
Originating Brain Receives Outcome
↓
Next action determined
↓
Request closed, escalated, or routed onward
Result Types
• recommendation delivered
• decision recorded
• approved for next stage
• blocked pending evidence
• routed onward
• escalated
• monitoring only
• failed execution
• integrity breach detected
Result Handoff Rules
• every result must map to request lineage
• results must be visible to originating Brain
• HeadOffice retains visibility for cross Brain requests
• ambiguous completion messages are invalid
• done is not an acceptable governed outcome
• every result must state what happened and what happens next
Handoff Integrity Rule
A result without next step clarity is structurally weak.
A result without lineage is structurally unsafe.
A result without visibility is operationally incomplete.
Connector Governance Rules
Rule 1 Routing Before Execution
No cross Brain execution begins before routing is declared.
Rule 2 Primary Brain Must Be Visible
If multiple Brains are involved, one Brain must be declared primary.
Rule 3 Request Lineage Must Be Preserved
Offer, experiment, intake, and parent request linkages must remain visible.
Rule 4 Tasks Are Subordinate To Requests
Task convenience must not override request governance.
Rule 5 Signals Trigger Action
Signals initiate the chain, structured requests govern the work.
Rule 6 Escalation Remains Inside Lineage
Escalation is a governed branch of the same chain.
Rule 7 Result Return Is Mandatory
Cross Brain work is incomplete until outcome is returned.
Rule 8 HeadOffice Visibility Is Required
HeadOffice must see request health and closure state.
Rule 9 Connector Logic Must Be Expandable
Architecture must support future Brains and automation.
Rule 10 Informal Cross Brain Communication Is Non Canonical
If not traceable through request lineage, it is not valid precedent.
Practical Interpretation
In MWMS operation:
Research Brain does not casually pass an idea to Affiliate Brain.
Affiliate Brain does not silently ask Ads Brain for creative direction.
Finance Brain does not appear only at the end of risk.
SIT does not operate as detached alarm logic.
HeadOffice does not rely on memory to understand cross Brain state.
Instead:
• structured request created
• routing determines ownership
• tasks created where needed
• signals remain visible
• escalation controlled
• results return through same chain
• HeadOffice can inspect full path
That is the correct connector precedent.
Outcome
MWMS Brain Connector Architecture creates the structural transport layer for MWMS.
It provides:
• controlled cross Brain communication
• stable request lineage
• governable signal movement
• escalation discipline
• clean result return logic
• strong HeadOffice visibility
• foundation for dashboards and automation
Without this layer, MWMS becomes conversational.
With this layer, MWMS becomes operational.
Change Log
Version v1.1
Date 2026-03-31
Authority HeadOffice
Change:
Title updated to remove dash character in accordance with MWMS Page Naming Standard clarification.
Naming rule reinforced:
Cross Brain pages begin with MWMS.
Single Brain pages begin with Brain name.
No dash characters permitted in page titles.