Document Type: Reference
Status: Reference Architecture
Authority: MWMS HeadOffice
Applies To: Entire MWMS ecosystem
Parent: MWMS Canon
Version: v1.1
Last Reviewed: 2026-03-15
Purpose
This document explains how the MWMS ecosystem actually operates as a working system.
It defines:
• the core system components
• how Brains communicate
• how work moves through MWMS
• where data is stored
• how governance documents are used
• how execution becomes outputs
This is the wiring diagram for MWMS.
Scope
This reference applies to:
• the full MWMS ecosystem
• the interaction between humans, WordPress, Supabase, executors, and Canon
• cross-brain task movement and execution flow
• storage and enforcement-layer visibility
• system-level understanding of how MWMS functions in practice
This document defines how MWMS is wired as an operating system.
It does not govern:
• decision ownership by itself
• Brain authority by itself
• capital approval by itself
• individual Brain operating rules by themselves
• detailed schema implementation by itself
• plugin build instructions by themselves
Those remain governed by the MWMS – Decision Authority Matrix, MWMS – Brain Registry, Finance Brain, SIT Brain, MWMS – Supabase Task Schema Standard, and related governance documents.
Definition / Rules
MWMS System Components
MWMS is built from five connected layers.
- Humans (Executive Authority)
Humans initiate, approve, and govern high-stakes actions.
• Martyn Walker
• M
Humans approve:
• structural changes
• capital decisions
• escalation outcomes
- WordPress (Control Panels)
WordPress is the MWMS operational interface.
It provides:
• Brain admin pages
• dashboards
• task viewers
• intake forms
• reporting panels
WordPress does not do the work.
It is the control panel where humans interact with the system.
- Supabase (System Memory + Task Database)
Supabase is MWMS system-of-record storage.
It stores:
• tasks
• task events
• outputs / logs
• structured records (decisions, lessons, etc.)
Supabase acts like:
• the organisational memory
• the work queue
• the audit log
- Executor / Workers (AI Execution Layer)
The executor is the mechanism that picks up work from Supabase and produces outputs.
The executor may be:
• a WordPress-triggered execution
• a scheduled worker
• a manual run
This layer performs:
• analysis
• drafting
• structured outputs
• report generation
• validation steps
The executor is where work happens.
- Canon + Governance (Rules Layer)
Canon pages are the governance layer.
They do not run code directly.
They define the rules that:
• humans must follow
• WordPress UI must enforce where possible
• executors must enforce in logic
Canon functions like:
• a constitution
• operating standards
• enforcement rules
How Brains Communicate
Brains do not chat directly.
Brains communicate using a structured request chain:
Brain Request → Task → Task Events → Output
This is the MWMS internal message system.
Example:
Affiliate Brain needs copywriting.
Instead of talking to Content Brain directly:
• Affiliate Brain creates a Brain Request targeting Content Brain
• that request becomes a Task in Supabase
• Content Brain worker executes it
• output returns and is logged
Canonical Work Flow (Execution Wiring)
All MWMS work must follow this flow:
Human or HeadOffice request
↓
WordPress intake UI (where applicable)
↓
Brain Request (structured)
↓
Supabase task created
↓
Executor picks up task
↓
Task events logged (timeline)
↓
Output produced (artifact)
↓
HeadOffice review (if high-stakes)
↓
Decision record (if required)
↓
Lessons learned (if meaningful)
Where Rules Are Enforced
MWMS rules are enforced in three places.
A) Human Enforcement
Humans must follow Canon during:
• structural changes
• high-stakes decisions
• governance edits
B) UI Enforcement (WordPress)
Where possible, admin pages enforce rules.
Examples:
• Brain dropdowns only show registered Brains
• required fields enforced in request forms
• warnings shown when in build / production layers
C) Executor Enforcement (Hard Rules)
Executors enforce rules through logic.
Examples:
• reject tasks missing Brain scope
• reject tasks targeting unknown Brains
• escalate tasks outside scope
• log rule violations as task events
What Happens If Rules Are Broken
When rule violations occur, MWMS must:
• record a task event: rule_violation
• flag via SIT Brain (or enforcement logic)
• escalate to HeadOffice if required
• suppress output if governance requires it
Rule violations do not get silently patched.
They get:
• logged
• escalated
• corrected
Data Storage Map
Where things live:
WordPress stores:
• UI pages
• admin workflows
• display panels
Supabase stores:
• tasks
• task_events
• structured records
• long-term system history
Canon pages store:
• definitions
• standards
• governance rules
Outputs may be stored:
• inline in Supabase
• in WordPress fields
• as external artifacts (files) referenced by task events
Relationship to Authority Structure
Authority Structure defines:
• who controls what
System Architecture defines:
• how work moves and where it is stored
Both are required.
Authority is governance.
Architecture is execution wiring.
Outcome
MWMS System Architecture ensures:
• everyone understands how MWMS actually functions
• Brains are coordinated through tasks, not chaos
• governance documents translate into enforceable logic
• the system remains scalable and auditable
Final Rule
If MWMS cannot show where work enters, where it is stored, how it is executed, and how rules are enforced, the architecture is incomplete.
System clarity is part of system safety.
Drift Protection
The system must prevent:
• Brains behaving like isolated tools instead of connected departments
• WordPress being mistaken for the execution engine itself
• governance pages existing without enforcement touchpoints
• work moving outside the request → task → event → output chain
• storage responsibilities between WordPress and Supabase becoming blurred
• rule violations being handled informally instead of through visible enforcement
MWMS architecture must remain traceable, layered, and enforceable.
Architectural Intent
MWMS – System Architecture exists to make the operating model of MWMS understandable as a real working system.
Its role is to show how executive control, interfaces, storage, execution, and governance connect together so MWMS can scale as a coordinated ecosystem rather than a loose collection of pages, plugins, and conversations.
Change Log
Version: v1.1
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 five-layer system model, brain-communication chain, canonical workflow, enforcement locations, rule-violation handling, data storage map, authority relationship, and intended system outcome. Added Document Type, Parent, Scope, Definition / Rules structure, Final Rule, Drift Protection, and Architectural Intent sections.
Version: v1.0
Date: 2026-03-13
Author: MWMS HeadOffice
Change: Initial creation of MWMS – System Architecture explaining how the MWMS ecosystem functions as a working system.
END – MWMS – SYSTEM ARCHITECTURE v1.1