Document Type: Standard
Status: Governance Standard
Authority: MWMS HeadOffice
Applies To: Entire MWMS ecosystem
Version: v1.2
Last Reviewed: 2026-03-15
Parent: MWMS Canon
Purpose
The MWMS Brain Request System defines how work is requested, assigned, and processed between Brains within the MWMS ecosystem.
It ensures that:
• tasks are clearly defined
• responsibilities are respected
• work flows through the correct Brain
• governance rules are maintained
This system prevents chaotic task creation and ensures structured collaboration across the MWMS organisation.
Scope
This standard applies to:
• all operational work entering the MWMS ecosystem
• Brain-to-Brain task routing
• HeadOffice request validation and routing oversight
• request structure and assignment discipline
• traceable work handoff through Brains and AI employees
• alignment between governance requests and system task infrastructure
This document governs how work requests must be created, routed, and processed across MWMS.
It does not govern:
• detailed Brain-internal workflow design by itself
• canon-level authority decisions by themselves
• capital approval by itself
• compliance rulings by themselves
• plugin implementation details by themselves
• unstructured human ideation before formal request entry
Those remain governed by HeadOffice, Finance Brain, SIT Brain, the MWMS Brain Interaction Protocol, and related system architecture documents.
Definition / Rules
Core Principle
Brains do not perform random work.
All operational work must enter the system through a Brain Request.
A Brain Request represents a structured instruction asking a Brain to perform a task within its defined scope.
Requests ensure that:
• the correct Brain performs the task
• responsibilities remain clear
• system activity remains traceable
Request Flow
The MWMS ecosystem processes work through a structured request chain.
Human Executive Authority
↓
HeadOffice
↓
Brain Request
↓
Assigned Brain
↓
AI Employee
↓
Operational Output
Every operational task must pass through this flow.
Routing Responsibility
HeadOffice is responsible for validating and routing Brain Requests.
HeadOffice must ensure:
• the request belongs to a valid Brain
• the request falls within that Brain’s operational scope
• the request is clearly defined
If a request does not meet these conditions, it must be clarified or rejected before entering the system.
Brain Request Structure
Each Brain Request must contain the following information:
• Request ID
• Requesting Authority
• Target Brain
• Task Description
• Priority Level
• Requested Output
These fields ensure the task can be clearly understood and executed.
Requesting Authority
Brain Requests may originate from the following authorities:
• Human Executive Authority
• HeadOffice
• Approved Brains (within scope)
Requests must always identify the requesting authority.
Target Brain
Each request must specify the Brain responsible for executing the task.
Examples include:
• Affiliate Brain
• Research & Intelligence Brain
• Finance Brain
• Risk Brain
• Operations Brain
Requests must not be assigned to multiple Brains simultaneously.
If collaboration is required, separate requests must be created.
Task Description
The task description must clearly define:
• the work required
• the context of the request
• any relevant information needed to complete the task
Ambiguous requests should be clarified before execution.
Priority Levels
Requests may include a priority level.
Possible priority levels include:
• Low
• Normal
• High
• Critical
Priority helps the Brain determine task urgency.
Requested Output
Each request must define the expected output.
Examples include:
• analysis report
• marketing copy
• campaign structure
• system diagnosis
Outputs should be structured and actionable.
Brain Processing
Once a Brain receives a request, the Brain may:
• analyse the request
• assign the task to an AI employee
• generate the requested output
Brains must only process requests that fall within their operational scope.
Requests outside scope must be redirected or escalated.
Cross-Brain Collaboration
If a task requires collaboration between multiple Brains:
• the initial Brain may complete its portion of the task
• a new Brain Request may be generated for the next Brain
• the process continues until the final output is produced
Example:
HeadOffice → Affiliate Brain
Affiliate Brain → Content Creation Brain
Content Creation Brain → Media Buying Brain
Each stage creates a traceable request chain.
System Architecture Alignment
Within the MWMS technical architecture, Brain Requests are mapped to the operational task system.
The typical execution chain is:
Brain Request
↓
System Task
↓
Task Event Logging
↓
Operational Output
This structure allows the ecosystem to track:
• task creation
• task processing
• system performance
• output generation
This integration allows MWMS to connect governance rules with the Supabase task infrastructure used by the operational system.
Governance Enforcement
The SIT Brain may monitor Brain Requests to detect:
• scope violations
• governance breaches
• inefficient task routing
If violations are detected, the issue must be escalated to HeadOffice.
Request Logging
All Brain Requests should be logged where possible.
Logs allow the ecosystem to track:
• task history
• system performance
• decision accountability
This supports long-term system intelligence and organisational learning.
Governance Rule
Brains may only perform tasks that arrive through the Brain Request system.
No Brain may accept informal or undefined instructions.
This rule ensures that the MWMS ecosystem remains organised, traceable, and governed.
Outcome
The Brain Request System provides a structured workflow for the MWMS organisation.
It ensures that work flows through the system in a controlled and traceable manner.
This protects the ecosystem from:
• chaotic task creation
• responsibility confusion
• governance violations
Final Rule
No Brain should begin operational work unless the request is structured, routed, and visible through the Brain Request system.
Informal work is non-compliant work.
Drift Protection
The system must prevent:
• Brains accepting undefined or informal instructions
• work being routed to the wrong Brain without validation
• one request being used to create uncontrolled multi-Brain execution
• ambiguous task descriptions entering the system unchallenged
• request processing occurring without logs or traceability
• governance oversight being bypassed through convenience-based task handling
The Brain Request System must remain structured, explicit, and auditable.
Architectural Intent
MWMS – Brain Request System exists to make work entry and routing across MWMS controlled, traceable, and Brain-safe.
Its role is to ensure that every operational task enters the ecosystem through a governed request structure so the organisation scales through disciplined workflow rather than ad hoc instruction chains.
Change Log
Version: v1.2
Date: 2026-03-15
Author: MWMS HeadOffice
Change: Rebuilt page to align with the locked MWMS document standard for this cleanup pass. Preserved the original purpose, core principle, request flow, routing responsibility, request structure, authority fields, priority model, requested-output logic, Brain processing, cross-Brain collaboration chain, system architecture alignment, governance enforcement, request logging, governance rule, and intended organisational outcome. Added Document Type, Parent, Scope, Definition / Rules structure, Final Rule, Drift Protection, and Architectural Intent sections.
Version: v1.1
Date: 2026-03-13
Author: MWMS HeadOffice
Change: Structured governance version of the MWMS Brain Request System defining how work is requested, assigned, and processed between Brains.
Version: v1.0
Date: Earlier version
Author: MWMS HeadOffice
Change: Initial concept for governed Brain request routing across the MWMS ecosystem.
END – MWMS – BRAIN REQUEST SYSTEM v1.2